Huigr王1. 单例模式最初要解决的那个问题，以及它存在的边界
1.1 为什么需要“只有一个实例”
如果你手头有一些实际项目经验，一定会遇到这样的情况：数据库连接池被反复初始化、日志系统被多个模块各自创建了自己的副本、配置对象在程序的不同地方读到了不同的值。这些问题表面上是“并发”“生命周期”问题，本质上都是一个：同一种资源，被多个实例同时管理了。
单例模式就是来解决这个问题的。它的定义很简单——保证一个类在整个进程生命周期中只有一个实例，并提供一个全局访问点。但定义简单，不代表实现简单。我在很长一段时间里，也用错过这个模式，把它当成了“全局变量的美化版”，后来在排查一个线上事故时才真正体会到这里面的门道。
从使用场景上说，单例模式最合理的用途集中在三类对象上：
| 类型 | 典型例子 | 为什么需要单例 |
|---|---|---|
| 有状态的中心管理器 | 连接池、线程池、事件总线 | 多处创建会造成资源重复分配和状态不一致 |
| 昂贵对象的共享容器 | 配置中心、缓存管理器 | 初始化成本高，重复创建是一种浪费 |
| 全局唯一的服务出口 | 日志记录器、监控上报器 | 它本身就必须是全系统共享的“唯一通道” |
注意，这三个场景的核心共同点是“多处访问同一资源”，而不是“方便全局访问”。如果你只是想让代码里随便哪个地方都能拿到一个对象，那大概率是在制造隐藏的耦合，而不是在运用设计模式。
1.2 单例模式与全局变量的本质区别
很多初学者会把单例模式看成“更优雅的全局变量”，这个理解方向不能说错，但至少是不完整的。全局变量的问题在于：任何代码都能极其随意地修改它、覆盖它，而且没有任何一道“关卡”来约束创建时机。单例模式在建構上加了访问控制，它保证了“实例只会被创建一次”，并且“创建过程中所有依赖关系是可控的”。
打个比方：全局变量就像是小区门口那块谁都能写一笔的公告板，张三写两行，李四擦掉重写，最后公告板上内容是谁留下的没人能说清；单例模式更像物业统一管理的门禁系统，所有进出人员都走同一道闸机，谁进来的、什么时候进来的、进来了多少次，都被记录在案。
这里的关键点在于：单例模式的价值不在“全局可见”，而在“可控的唯一性”。 当你决定把一个类设计成单例时，你实际上是在说：这个类的状态必须在整个进程空间里保持一致。如果这个一致性问题本身不存在，单例模式就失去意义了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 五种语言下的单例写法：从最稳妥到最简洁
不同的语言对单例模式的表达方式差异很大。有些语言天生提供了机制让单例实现变得非常简洁，有些语言则需要在内存模型层面格外小心。下面我基于自己的实际使用经验，按语言逐一说明。
2.1 Java：从双重检查锁到枚举
Java里的单例模式写法人人都会背，但真正经得起推敲的不多。最经典的写法是懒加载加双重检查锁（Double-Checked Locking）:
java复制public class ConfigManager {
private static volatile ConfigManager instance;
private ConfigManager() {
// 初始化配置读取
}
public static ConfigManager getInstance() {
if (instance == null) {
synchronized (ConfigManager.class) {
if (instance == null) {
instance = new ConfigManager();
}
}
}
return instance;
}
}
这段代码在Java 5之后是正确的，因为volatile保证了实例发布时的可见性。但需要注意一点：不加volatile的双检锁写法在Java 5之前是有问题的，原因是我在下一章会展开说明的指令重排序问题。
如果追求简洁且不介意用枚举，那这是更推荐的方式：
java复制public enum ConfigManager {
INSTANCE;
private Properties config;
ConfigManager() {