佚格麻瓜你有没有遇到过这种场景：写日志的时候，两个线程同时在写同一个文件，日志顺序全乱了；或者一个全局配置对象、一个数据库连接池，在代码里被 new 了无数次，内存里堆着一堆“重复但有状态差”的对象。这种时候，你需要的其实就是一个“全局只有一份”的实例——这就是设计模式里最基础、也最容易被低估的单例模式。
我见过不少同学对单例的理解停留在“把构造函数设成 private，然后 getInstance() 返回一个 static 变量”，结果一到多线程、反序列化、反射这些场景就翻车。也有朋友在面试时被问到“饿汉和懒汉怎么选”的时候只会背答案，说不出背后的类加载机制和内存可见性问题。这篇文章我就从饿汉式一路拆到懒汉式，把单例模式的线程安全、延迟加载、防破坏方案、源码应用场景，一次讲透。无论是你在准备设计模式期末、Java 设计模式大作业，还是已经在看 Android 源码解析与实战，这篇都能给你一个可以直接抄作业的答案。
1. 为什么“仅此一份”这么重要：单例模式要解决的问题
1.1 三个必须“全局唯一”的典型场景
先说场景，不然光讲概念没意思。
第一个场景是日志记录器。日志框架在整个应用生命周期里只应该有一个实例，因为日志写入涉及文件流的打开、缓存的刷新、锁的竞争。如果你每次调用 Logger.getInstance() 都 new 一个对象，相当于反复打开同一个文件句柄，轻则日志内容错乱，重则文件锁冲突导致死锁。我早年写一个控制台工具时，就是把 Logger 当普通类用，结果多线程下日志一条条“接龙”乱序，排查了半天才发现问题出在对象不唯一。
第二个场景是线程池。线程池的设计初衷就是复用线程、控制并发数。如果你每次需要异步任务就创建一批新线程，系统资源很快会被打满，线程切换开销也会拖垮性能。所以 ExecutorService、连接池这类资源型对象，天然适合做成单例。
第三个场景是配置管理器。配置文件的内容一般不会在运行中频繁变化，你也不希望每个模块各自加载一遍配置文件，然后内存里存着几份不同的配置副本。配置源变了之后，有的模块读新值、有的模块还在读旧值，这种状态分裂带来的 bug 极其隐蔽。全局只有一个配置对象，至少能保证同一时刻内存里只有一份配置状态。
1.2 单例不是“全局变量”的换皮
很多人说单例就是个“优雅一点的全局变量”，这话只对了一半。全局变量允许程序任意位置修改，没有创建时机控制，也没有唯一性约束。单例模式的关键在于两个约束：一是构造器私有化，保证外部无法通过 new 随意创建；二是通过一个静态方法暴露唯一实例，由类自己控制实例的创建时机和创建方式。
这种“对象自己管理自己生命周期”的思路，才是单例模式的核心——它本质上是把“全局唯一”这个业务约束，从程序员口头约定变成了语言层面的强制规则。你说它像个全局变量，也没毛病，但它是一个有纪律、有约束、有防护的全局变量。
1.3 饿汉和懒汉的核心分歧：创建时机
同一个单例模式，江湖上分出了两派：饿汉和懒汉。饿汉的意思是“我很饿，类一加载我就把实例创建好，谁来了都是同一个”；懒汉的意思是“我很懒，你不调 getInstance() 我绝不创建实例，第一次被用到才动手”。
分歧的本质其实是三个问题的取舍：类加载时是否创建实例、多线程下是否安全、是否需要额外同步机制。饿汉牺牲了启动速度换来了线程安全；懒汉保留了延迟加载，但必须自己处理线程安全问题。别小看这个“创建时机”，它决定了单例在不同运行环境里的表现，也决定了你在面试和实战中能不能把话说圆。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 饿汉式：用类加载机制换一份“天生线程安全”
2.1 最简洁的写法与背后的 JVM 原理
先给出饿汉式的标准写法：
java复制public class EagerSingleton {
private static final EagerSingleton INSTANCE = new EagerSingleton();
private EagerSingleton() {
}
public static EagerSingleton getInstance() {
return INSTANCE;
}
}
这段代码短得不能再短，但它背后有个非常重要的机制：JVM 在类加载阶段会执行 static 字段的初始化，而这个初始化过程由 JVM 保证只执行一次，并且在多线程环境下天然是安全的。换句话说，类加载器对 static 变量的初始化做了“隐式加锁”，所有线程在访问这个类之前都必须等类初始化完成。即使 100 个线程同时调用 getInstance()，它们拿到的也是同一个创建好的对象，不存在竞态条件。
在 C# 里逻辑也类似，CLR 的类型初始化器（.cctor）同样保证了 static 字段只初始化一次：
csharp复制public sealed class EagerSingleton
{
private static readonly EagerSingleton instance = new EagerSingleton();
private EagerSingleton() { }
public static EagerSingleton Instance => instance;
}
注意 C# 版我加了 sealed，这是为了禁止类被继承后通过子类破坏单例约束，Java 里如果担心继承问题，也可以把类声明为 final。
2.2 饿汉的代价：启动即创建
饿汉的隐患也很明显：实例在类加载时就创建了，不管你之后用不用。假设你有一个配置对象，内部要从远程配置中心拉取几千个配置项，这个拉取过程可能要几十毫秒甚至更久。如果这个类在应用启动阶段就被加载，那启动时间就被白白拖长了；如果项目里有一堆这样的饿汉单例，启动链路会变得非常重。
Android 开发对这个坑应该最有共鸣。一个 App 冷启动的时候，Application 类一加载，所有被引用的饿汉单例全部开始初始化。如果这些单例里有人访问网络、读取数据库、解析大文件，启动耗时的指标分分钟翻车。所以移动端对饿汉式的态度一向谨慎——不是不能用，而是要确认“启动必用”才行。
2.3 饿汉适合什么场景
根据我实际使用的经验，饿汉式在三种场景下是首选：
- 实例一定会在启动阶段被用到，不创建反而会出问题。
- 对象创建成本低，不涉及网络、数据库等重操作。
- 初始化不依赖运行时参数，不依赖其他模块的状态。
反过来，如果你的单例对象创建很重、或者可能很久都用不上，那就不要用饿汉。你省掉了加锁的逻辑，但可能换来更长的启动时间和无意义的内存占用，这笔账不划算。
3. 懒汉式：从线程不安全到双重检查锁的演进之路
3.1 第一版懒汉：代码好看，线程不安全
懒汉式最朴素的写法长这样：
java复制public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}
逻辑很直白：第一次调用时才发现 instance 是 null，那就 new 一个，之后所有调用直接返回旧对象。副作用是什么？线程不安全。设想线程 A 和线程 B 同时进入 getInstance()，A 先判断 instance == null 成立，正准备 new；B 也判断 instance == null 成立，也开始 new。结果两个线程各创建了一个对象，单例不再单。
问题出在哪呢？if (instance == null) 和 new LazySingleton() 是两步操作，不是一个原子操作。线程切换可以发生在任何一个指令间隙，所以“判断为空”和“创建对象”之间有一个时间窗口，这个窗口就是竞态条件所在。
3.2 全方法加锁：线程安全了，性能牺牲了
最简单的修复方式是给 getInstance() 方法加上 synchronized：
java复制public static synchronized LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
加了锁之后，所有线程进入方法前必须先拿到对象锁，线程安全的问题解决了。但这带来一个新的问题：即使 instance 已经创建完成，后续所有调用 getInstance() 的线程仍然需要排队拿锁。读操作本质上只做了一次 null 判断，却要付出整个方法锁的代价。在高并发场景下，getInstance() 一般是调用很频繁的方法，这种“即使不需要同步也必须等锁”的设计就成了性能瓶颈。
我在性能测试里实测过，一个只做 null 判断的方法，不加锁时每秒可以扛住几百万次调用，加上 synchronized 后吞吐量可能下降一到两个数量级。所以在读多写少的场景里，直接锁整个方法是非常不划算的。
3.3 双重检查锁（DCL）：要线程安全，也要性能
为了“既安全又高效”，业界给出了双重检查锁方案：
java复制public class DclSingleton {
private static volatile DclSingleton instance;
private DclSingleton() {
}
public static DclSingleton getInstance() {
if (instance == null) {
synchronized (DclSingleton.class) {
if (instance == null) {
instance = new DclSingleton();
}
}
}
return instance;
}
}
它做了一层“先判断，后加锁，再判断”的流程。第一次 if (instance == null) 是为了过滤掉绝大多数“实例已经存在”的调用，让读操作不需要进入锁竞争；synchronized 块保证了只有一个线程能进入创建逻辑；第二次 if (instance == null) 是为了防止两个线程同时通过第一次检查后，一个线程创建完释放锁，另一个线程又重复创建。
到这里，DCL 看起来已经完美了，但它还藏着一个大坑：instance 字段必须声明为 volatile。很多人知道要加 volatile，但说不清为什么。
关键在于 new 操作在底层并不是一个原子动作，它大致分解为三步：
- 在堆上分配一块内存空间；
- 在内存上执行构造函数，初始化对象；
- 把引用指向这块内存地址。
在没有 volatile 的情况下，CPU 和编译器可能为了优化效率发生指令重排序，让第 3 步跑到第 2 步前面。也就是说，引用已经指向了一块内存，但对象还没完成初始化。此时另一个线程进来了，第一次 if (instance == null) 发现 instance 不为空，于是直接返回了一个“半初始化”的对象，程序接下来访问这个对象的字段时，拿到的全是默认值或 null。
volatile 在这里干了两件事：一是禁止指令重排序，保证引用赋值一定发生在对象初始化完成之后；二是保证线程之间的可见性，一个线程写入了 instance，其他线程能立即看到最新值。
C# 的 DCL 写法也要用 volatile 关键字：
csharp复制public sealed class DclSingleton
{
private static volatile DclSingleton instance;
private static readonly object lockObj = new object();
private DclSingleton() { }
public static DclSingleton Instance
{
get
{
if (instance == null)
{
lock (lockObj)
{
if (instance == null)
{
instance = new DclSingleton();
}
}
}
return instance;
}
}
}
有一点值得注意，DCL 的线程安全性在 Java 5 之后的 JMM（Java 内存模型）里才被完整保证。Java 5 之前，即使加了 volatile，指令重排序的语义也没有现在这么严格，所以早期教材里的 DCL 方案其实是不可靠的。现在主流 JDK 版本下，DCL 是完全可用的，面试时如果能主动提一句“JDK 5 之后内存模型修正了 volatile 语义”，会是很加分的细节。
3.4 静态内部类：懒加载和线程安全的另一个优解
如果你觉得 DCL 同时用 synchronized 和 volatile 两套机制有点重，其实还有一个更轻的思路：静态内部类。
java复制public class HolderSingleton {
private HolderSingleton() {
}
private static class Holder {
private static final HolderSingleton INSTANCE = new HolderSingleton();
}
public static HolderSingleton getInstance() {
return Holder.INSTANCE;
}
}
这个方案的原理很巧妙。JVM 在类加载时不会加载内部类 Holder，只有显式调用 Holder.INSTANCE 时，Holder 才会被类加载器加载。加载类的同时，INSTANCE 的初始化由 JVM 保证只执行一次，线程安全。所以它天然同时满足了两个条件：懒加载（Holder 类第一次被调用时才创建实例）和线程安全（类加载机制保证）。
相比 DCL，静态内部类没有锁、没有 volatile，代码更简洁，也不存在指令重排序的风险。它唯一的限制是“只能在第一次 getInstance() 时创建实例”，如果你需要更精细的时机控制，比如在某个固定方法里显式 init，那就得换其他写法。
下面我把三种主流方案的差异放在一起：
| 实现方案 | 创建时机 | 线程安全 | 同步开销 | 代码复杂度 |
|---|---|---|---|---|
| 饿汉式 | 类加载时 | 由 JVM 保证 | 无 | 最低 |
| DCL | 第一次 getInstance() | volatile + synchronized | 首次创建后有判断开销 | 较高 |
| 静态内部类 | 第一次 getInstance() | 由 JVM 类加载机制保证 | 无 | 低 |
综合来看，静态内部类在“懒加载 + 线程安全 + 无锁”三个维度上都表现优秀，也是我个人在实际项目中用得最多的一种写法。
4. 反射与序列化：能毁掉单例的两个“幕后黑手”
4.1 setAccessible(true) 之后，单例还“单”吗
先问一个问题：一个构造函数是 private 的类，外部就真的无法创建对象了吗？不是。Java 的反射机制可以拿到构造器，然后调用 setAccessible(true) 把访问权限放开，直接创建新对象。
java复制Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton instance1 = constructor.newInstance();
Singleton instance2 = constructor.newInstance();
跑完之后，instance1 和 instance2 是两个不同的对象，单例约束被完全击穿。虽然日常业务代码里没人会这么写，但在框架开发、工具类库这类对稳定性要求极高的场景里，这是必须考虑的攻击面。
最简单的防御办法是加一个私有标记位，构造函数里发现标记位已被占用就直接抛异常：
java复制public class SafeSingleton {
private static boolean flag = false;
private SafeSingleton() {
synchronized (SafeSingleton.class) {
if (flag) {
throw new RuntimeException("单例构造器被非法调用");
}
flag = true;
}
}
}
不过这里有个细节容易踩坑：懒汉式单例的 instance 字段是延迟初始化的，如果 flag 不是 volatile，一个线程在构造函数里把 flag 写成 true，另一个线程通过反射调用构造器时可能看不到最新值。所以标记位字段最好也声明为 volatile。
4.2 序列化之后的反序列化，相当于偷偷 new 了一次
Java 对象实现了 Serializable 接口后，可以通过 ObjectOutputStream 写入文件或网络流，再用 ObjectInputStream 读回来。麻烦的是，反序列化底层本质上是“重新创建对象”的过程，即使构造函数是 private，也不会调用它，而是通过特殊机制在内存中再生出一个对象。
也就是说，一个单例对象被序列化后再反序列化，会得到一个全新的实例，单例约束照样失效。解决办法是提供一个 readResolve() 方法：
java复制public class SerializableSingleton {
private static final SerializableSingleton INSTANCE = new SerializableSingleton();
private SerializableSingleton() {
}
public static SerializableSingleton getInstance() {
return INSTANCE;
}
private Object readResolve() {
return INSTANCE;
}
}
readResolve() 的机制是：反序列化完成后，ObjectInputStream 会检查对象是否有 readResolve()，如果有，就用这个方法返回的对象顶替反序列化产生的对象。所以在方法里直接返回现有的单例对象，新产生的那个“假对象”就会被丢弃，不会污染单例状态。
C# 的 BinaryFormatter 序列化机制也面临同样的问题，需要通过实现 ISerializable 接口或者标记 [OnDeserialized] 回调来处理。这个细节在做分布式缓存、RPC 传输对象时特别重要，我见过不少项目因为没写 readResolve()，单例对象从 Redis 里取出来之后“变成”了新对象，导致缓存里的状态和本地状态不一致。
4.3 最省心的方案：枚举单例
如果希望从语言底层就堵死反射和序列化两个漏洞，Java 从 JDK 1.5 开始提供的枚举类型是最强的答案：
java复制public enum EnumSingleton {
INSTANCE;
public void doSomething() {
}
}
枚举实例的创建由 JVM 保证唯一，且枚举类没有公开的构造器，反射的 newInstance() 对枚举类型是禁止的，序列化机制对枚举也做了特殊处理：反序列化时返回的是同一个枚举实例，不会新建对象。所以 Joshua Bloch 在《Effective Java》里才会说，枚举是实现单例最好的方式。
当然，枚举单例也不是毫无缺点。它的可读性不如传统类清晰，部分团队会觉得这种写法比较“奇技淫巧”；在 C# 里也没有完全等价的语法糖。如果项目规范和团队习惯偏向传统写法，静态内部类加 readResolve() 是更“普通话”的选择。
5. 源码里的单例与实战选型判断
5.1 Android 和经典框架里的单例应用
如果你看过 Android 源码，会发现单例模式无处不在。最典型的是 EventBus 的 getDefault()，它就是标准的双重检查锁单例。还有一个容易被忽略的例子是系统服务（SystemService），比如 WindowManager、InputMethodManager，它们在系统进程里是全局唯一的服务对象，应用进程通过 Context.getSystemService() 拿到的是它的代理或包装。这种“服务提供方单例 + 调用方代理”的架构，本质上就是避免频繁创建重量级系统对象的设计。
再比如 LayoutInflater.from(context)，它的内部实现会从 Context 中取出系统服务，然后返回一个可用的 LayoutInflater 实例。如果每次 inflate 布局都新建一个 LayoutInflater，那内存和布局解析的性能开销根本无法接受。框架选择单例的原因很朴素：对象创建和销毁成本高、全局只有一个更合理、参数传递不方便。
5.2 单例的阴暗面：可测试性与全局状态污染
单例模式最大的隐患不是什么线程问题，而是可测试性。单例持有全局状态，意味着一个测试用例修改了单例的内部状态，下一个测试用例可能会被污染。更麻烦的是，单例很难在测试里 mock——因为 getInstance() 是静态方法，你没法在不同测试场景里轻松替换它的实现。
这几年我写服务端 Go 和 Java 项目，尝到 DI（依赖注入）框架的甜头之后，已经很少手写单例了。Spring 的 Bean 默认就是单例的，但它把“实例唯一”这件事交给容器管理，你在代码里写的是普通类，注入的时候拿到的都是同一个实例。这样做的好处是保持了代码的可测试性，同时由容器负责生命周期管理。
所以我会建议：如果你的项目引入了 Spring 这类 IoC 容器，尽量让容器管理单例 Bean，而不是自己手写 static 单例；没有容器的时候，再考虑手写饿汉或静态内部类单例。
5.3 选型判断清单与常见误用
我把选型逻辑整理成一个清单，供你直接对照使用：
- 实例一定会在启动阶段用到，而且初始化不重：选饿汉式，最简单。
- 实例可能用不上，或者创建重、依赖运行时参数：选静态内部类。
- 需要绝对防反射、防序列化破坏：选枚举单例。
- 需求要求“只有调用某个用户自定义 init 方法才创建”：老老实实写 DCL。
- 多线程环境下，绝不使用没加锁的裸懒汉。
- 如果项目已经使用 IoC 容器：交给容器，不要重复造轮子。
常见误用也有几类。第一类是把可变状态全部塞进单例，导致类与类之间产生隐形依赖。第二类是在 Android 里用单例持有 Activity 或 Context 引用，这基本是内存泄漏的教科书级错误——单例的生命周期长于 Activity，一旦持有 Activity 引用，Activity 就永远无法被回收。第三类是“为了单例而单例”，一个无状态工具类根本没必须保证全局唯一，线程安全的静态方法就够了，单例反而限制了扩展性。
6. 源码里的单例与实战选型判断的补充：我的一点个人体会
写到这里，单例模式的主体内容已经讲完了。最后再分享一些我做设计模式大作业、看源码解析、在实际项目里和单例打交道的体会。
你要是在准备期末考试或者面试，我建议把重点放在 DCL 的 volatile 原理和静态内部类的类加载时机上。面试官问单例，大概率是想通过这个简单模式考察你对线程安全、内存模型、类加载机制的理解深度。能把“new 操作三步、指令重排序、volatile 禁止重排序”这条线完整讲清楚，就已经超过大多数候选人了。
如果你是在实际项目里写代码，我的倾向非常明确：Java 项目无特殊需求就用静态内部类或枚举，C# 项目用 Lazy<T>（它内部实现了一套线程安全且延迟加载的机制）或者静态构造函数，Spring 项目直接交给容器。不要为了炫技去写花里胡哨的线程安全方案，生产环境最重要的是可读性和可维护性。
最后一个小技巧：如果你写的是会被序列化的单例，一定要记得实现 readResolve()，顺便加上 serialVersionUID。这个字段不是可有可无——散落在生产环境里的 invalid class 异常，很多就是因为它缺失导致的兼容性问题。单例模式本身不难，难的是在每个环境里都能保持“单”的语义，这份严谨，才是设计模式带给开发者最大的价值。