单例模式的线程安全实现方案：从基础到进阶
单例模式的核心就是“保证整个应用中只有一个实例”，但线程安全可不是简单加个锁就行。我见过不少新手上来就写个“懒汉式”，结果多线程一跑就创建出好几个实例。其实从基础的饿汉式到进阶的双重检查锁，每种实现都有它的适用场景，咱们一个个说清楚。
饿汉式：最简单但可能“浪费粮食”的方案
饿汉式应该是你最早接触的单例写法吧？类一加载就创建实例，代码长这样：
public class HungrySingleton {
// 类加载时直接初始化实例
private static final HungrySingleton instance = new HungrySingleton();
// 私有构造方法，防止外部实例化
private HungrySingleton() {}
// 提供全局访问点
public static HungrySingleton getInstance() {
return instance;
}
}
这种写法线程安全吗？绝对安全！因为Java虚拟机在加载类时，会保证静态变量的初始化是线程安全的，多个线程同时加载类也只会创建一个实例。但问题也很明显——太“饿”了，不管你用不用这个实例，它都会在类加载时就占用内存。如果这个单例里持有数据库连接、缓存等 heavy 资源，而项目启动后很久才用到它，就会白白浪费资源。我之前维护过一个老项目，里面十几个工具类单例全用饿汉式，结果项目启动时间比同类项目慢了近20秒，后来优化成懒加载才解决。
懒汉式：按需加载但要小心“并发陷阱”
懒汉式的思路很贴心：“你不用我，我就不初始化”，真正做到按需加载。但普通的懒汉式是线程不安全的，咱们先看“错误示范”：
// 错误示范：普通懒汉式（线程不安全）
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {}
public static LazySingleton getInstance() {
if (instance == null) { // 多线程下可能同时进入这里
instance = new LazySingleton();
}
return instance;
}
}
你猜怎么着？如果两个线程同时走到if (instance == null)，都判断为null，那就会创建两个实例！我之前在测试环境用线程池模拟10个线程并发调用，结果日志里打印出3个不同的实例hashCode，当时还以为是日志错了，后来debug才发现问题出在这儿。
那给getInstance()加个synchronized锁总安全了吧？
// 线程安全但性能差的懒汉式
public static synchronized LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
安全是安全了，但每次调用getInstance()都要加锁，哪怕实例已经创建好了。高并发场景下，成千上万个线程排队等锁，性能损耗可不小。我朋友的项目就踩过这个坑，一个高频调用的单例用了这种写法，高峰期接口响应时间从20ms涨到了200ms，后来换成双重检查锁才降下去。
双重检查锁（DCL）：性能与安全的“黄金平衡”
双重检查锁（Double-Checked Locking，DCL）是现在最常用的单例实现之一，既解决了懒加载问题，又避免了频繁加锁。先看代码：
public class DCLSingleton {
// 注意这里要加 volatile！
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;
}
}
你可能会问：“为什么要检查两次？” 举个例子：线程A和线程B同时通过第一次instance == null，线程A先抢到锁，创建实例后释放锁；这时候线程B进入锁，如果没有第二次检查，就会再创建一个实例——所以第二次检查是为了“锁内确认”。
但这里有个关键细节：instance变量必须加volatile关键字。我见过不少人写DCL时漏了这个，结果偶尔出现NPE（空指针异常）。这是因为instance = new DCLSingleton()这行代码，在JVM里其实分三步：
instance指向内存地址。如果不加volatile，JVM可能会为了优化性能而“指令重排”，变成1→3→2。这时候线程A刚执行完步骤3（instance非null了），线程B来获取实例，拿到的是还没初始化的“半成品”，一调用方法可不就NPE了？Java官方文档里明确提到，volatile可以禁止这种指令重排，保证实例创建的完整性（你可以去Java官方文档查volatile的内存语义）。静态内部类：《Effective Java》推荐的“优雅方案”
如果你问我“日常开发中最推荐哪种单例实现？”，我会毫不犹豫推荐静态内部类。代码长这样：
public class StaticInnerClassSingleton {
private StaticInnerClassSingleton() {}
// 静态内部类，只有在调用getInstance()时才会加载
private static class SingletonHolder {
private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
}
public static StaticInnerClassSingleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种写法牛在哪儿？首先它是懒加载的——内部类SingletonHolder只有在getInstance()被调用时才会加载，实例在此时创建；其次它是线程安全的——Java虚拟机保证类加载过程是线程安全的，多个线程同时加载内部类也只会创建一个实例； 它不用加锁，性能和简洁度都拉满。《Effective Java》的作者Joshua Bloch在书中明确推荐这种方式，称它“结合了懒加载和线程安全的最佳特性”。我去年面试一家大厂时，面试官问“你认为最优雅的单例实现是什么？”，我答了这个方案，还解释了内部类的加载机制，当场就被追问后续技术面了。
为了让你更直观对比这几种实现，我整理了一张表，你可以根据项目场景选：
| 实现方式 | 线程安全 | 懒加载 | 优点 | 缺点 |
|---|---|---|---|---|
| 饿汉式 | 是 | 否 | 简单，绝对安全 | 可能浪费资源（类加载即初始化） |
| 带synchronized的懒汉式 | 是 | 是 | 简单，按需加载 | 性能差（每次调用都加锁） |
| 双重检查锁（DCL） | 是（需加volatile） | 是 | 性能好，懒加载 | 实现复杂，易漏写volatile |
| 静态内部类 | 是 | 是 | 简洁，性能好，无需加锁 | 不能通过反射完全防止实例化 |
（表格说明：“线程安全”指多线程环境下是否会创建多个实例；“懒加载”指是否在首次使用时才初始化实例）
单例模式的避坑指南：这些“坑”我踩过，你别再犯
学会了实现方案，不代表就能写出“绝对安全”的单例。我见过不少人把前面的代码背得滚瓜烂熟，结果一遇到反射、序列化就傻眼。这些藏在细节里的“坑”，才是区分新手和老手的关键。
坑点一：普通懒汉式的“并发失效”——我曾 改了3天bug
前面说过普通懒汉式（没加synchronized的那种）线程不安全，但你知道它具体怎么“不安全”吗？我之前帮朋友排查一个线上bug，他的代码里有个“配置管理器”单例，用的就是普通懒汉式。结果上线后发现，不同用户看到的配置偶尔会“串”——明明是A用户的配置，B用户刷新后也看到了。最后定位到问题：高并发下创建了3个配置管理器实例，每个实例缓存了不同用户的配置。
你可以自己写段测试代码复现一下：用线程池起20个线程，每个线程循环调用getInstance()并打印实例的hashCode，你会发现输出结果里有好几个不同的hashCode。这就是因为多个线程同时通过if (instance == null)，各自创建了实例。所以记住：只要用到多线程环境，普通懒汉式就别碰，哪怕你觉得“项目并发量不高”也不行——bug这东西，从来都是“你觉得没事，它就偏要找上门”。
坑点二：双重检查锁里漏写volatile——指令重排让你防不胜防
前面讲DCL时提过volatile不能漏，但我还是想再强调一次。去年带实习生做项目，他负责写一个“连接池管理器”单例，用了DCL却没加volatile。测试时一切正常，上线后偶尔报NPE，而且报错毫无规律——有时候一天一次，有时候三天一次。我们查了一周日志，最后在JVM的GC日志里发现线索：实例对象的初始化过程被指令重排了，线程拿到了还没初始化完成的实例。
后来让他加上volatile，观察了一个月，再也没出现过NPE。所以写DCL时，一定要顺手把volatile加上，就像写构造方法时顺手设为private一样，这是肌肉记忆级别的习惯。
坑点三：反射和序列化“暗度陈仓”——单例也能被“克隆”
你以为静态内部类实现的单例就“天衣无缝”了？太天真！反射和序列化能轻松“破解”大部分单例。先看反射怎么破坏单例：
// 用反射获取私有构造方法，强制创建实例
Class> clazz = StaticInnerClassSingleton.class;
Constructor> constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true); // 跳过访问权限检查
StaticInnerClassSingleton instance1 = (StaticInnerClassSingleton) constructor.newInstance();
StaticInnerClassSingleton instance2 = StaticInnerClassSingleton.getInstance();
System.out.println(instance1 == instance2); // 输出false！单例被破坏了
这段代码一跑，两个不同的实例就出来了。我之前面试时被问到这个问题，当时只知道静态内部类好，却答不出怎么防反射，结果错失了一个offer。后来查资料才知道，枚举单例是唯一能天然防止反射和序列化破坏的实现方式：
public enum EnumSingleton {
INSTANCE;
// 枚举的构造方法默认是private，且JVM保证枚举实例只能被创建一次
public void doSomething() {
// 业务逻辑
}
}
枚举为什么这么牛？因为Java虚拟机在加载枚举类时，会阻止通过反射创建枚举实例——如果你尝试用反射调用枚举的构造方法，会直接抛出IllegalArgumentException。而且枚举序列化时，会通过valueOf()方法获取已有实例，而不是创建新实例。《Effective Java》里也说：“枚举单例是实现单例模式的最佳方法”。不过日常开发中用枚举的不多，因为它相对“重量级”，而且有些框架（比如Spring）对枚举的支持不如普通类灵活。如果你对“绝对安全”有强需求（比如涉及分布式锁、配置中心这类核心组件），枚举单例可以优先考虑。
其实单例模式的线程安全，说难不难，说简单也不简单——关键在于把“为什么这么写”“哪里可能出问题”搞清楚，而不是死记代码。你可以先从静态内部类入手，日常开发足够用；如果遇到反射、序列化场景，再考虑枚举。要是你按这些方法试了，或者遇到了其他“坑”，欢迎回来留言告诉我，咱们一起把单例模式的细节抠得更透！
选单例实现方案这事儿，真不能一刀切，得看你项目具体情况。比如饿汉式吧，就像食堂阿姨打饭，不管你饿不饿先给你盛满——类一加载就把实例建好，好处是简单粗暴，线程安全绝对有保障，JVM加载类的时候就把静态变量初始化搞定了，多线程来抢也抢不出第二个实例。我之前有个项目，日志工具类用的就是饿汉式，因为启动时就需要加载配置，而且占用资源不多，反而启动快，后来换其他项目试了试懒加载，发现启动时间确实省了点，但日志工具这种常用的，饿汉式反而更省心。不过要是你那个单例里塞了数据库连接池、大缓存这些“重量级”东西，平时又不常用，那饿汉式就有点浪费了，像背着大石头跑步，没必要。
静态内部类就不一样了，它像个懂事的孩子，你不用它，它绝不出来捣乱——第一次调用getInstance()才慢悠悠初始化实例，完全按需加载。代码还特干净，不用操心锁的问题，JVM自己保证类加载安全，我现在写工具类单例基本都用这个，简单又优雅。要是你项目并发场景复杂点，想追求极致性能，那就试试双重检查锁（DCL），不过记着volatile关键字千万别漏，我见过有人漏了这个，线上跑着跑着就出NPE，查了半天才发现是指令重排搞的鬼，实例还没初始化完就让其他线程拿走了。至于枚举单例，那是安全到骨子里的，反射、序列化都破坏不了它，但就是有点“重”，像个全副武装的士兵，平时用着可能觉得没必要，除非项目里明确有这些安全坑要防，不然日常开发真用不太上。所以啊，平时开发优先选静态内部类和DCL，简单够用还灵活，除非面试官盯着问“怎么防反射破坏”，不然枚举不用急着上。
如何选择适合的单例实现方案？
选择单例实现方案需结合项目需求：若实例占用资源少、启动时即需加载，优先选饿汉式；若需懒加载且并发场景简单，静态内部类是优雅选择（代码简洁、性能好）；若涉及复杂并发控制且需极致性能，双重检查锁（DCL）更合适（需注意volatile关键字）；若需绝对防止反射/序列化破坏，枚举单例是唯一天然安全的方案，但相对重量级，日常开发中静态内部类和DCL更常用。
双重检查锁（DCL）中，volatile关键字具体起什么作用？
volatile在DCL中主要有两个作用：一是禁止指令重排，避免“实例引用已赋值但对象未初始化”的半成品状态（JVM可能将实例创建步骤重排，导致其他线程获取到未初始化实例）；二是保证可见性，确保一个线程对实例的修改能立即被其他线程看到。若省略volatile，多线程环境下可能出现空指针异常（NPE）或获取到不完整实例， DCL必须搭配volatile使用。
反射和序列化会破坏单例，如何解决？
反射可通过暴力访问私有构造方法创建新实例，序列化会将单例对象写入流再读出时创建新实例。解决方法：反射破坏可在构造方法中添加判断（若实例已存在则抛异常）；序列化破坏需重写readResolve()方法返回已有实例。但最彻底的方案是使用枚举单例——Java虚拟机天然禁止反射创建枚举实例，且枚举序列化时通过valueOf()获取已有实例，从根本上防止破坏，《Effective Java》明确推荐枚举单例为最佳方案。
枚举单例有哪些优缺点？
枚举单例的优点：天然线程安全（JVM保证枚举实例仅创建一次）、防反射/序列化破坏（无需额外代码）、实现简单（几行代码即可）。缺点：相对重量级（枚举类本质是继承Enum的类，比普通类占用更多资源）、灵活性低（无法继承其他类，若需扩展功能需额外设计）、部分框架（如Spring）对枚举的依赖注入支持不如普通类。 枚举单例适合对安全性要求极高的核心组件（如分布式锁、配置中心），日常工具类单例可优先考虑静态内部类。
单例模式在实际开发中有哪些常见应用场景？
单例模式适用于“全局唯一资源管理”场景：如数据库连接池（避免频繁创建/销毁连接）、日志管理器（确保日志写入顺序一致）、配置中心（集中管理配置信息，避免重复加载）、工具类（如日期格式化工具、加密工具，无需多实例）、线程池（全局统一管理线程资源）。 项目中常用的“Redis连接管理器”单例，通过静态内部类实现，确保多线程下仅创建一个连接池实例，既节省资源又避免连接冲突。
