双重检查锁（DCL）：从线程安全陷阱到完美实现
在Java并发编程中，单例模式是设计模式中最经典也是最容易出错的一个。其中，双重检查锁定（Double-Checked Locking, DCL）因其兼顾了延迟加载与性能而备受青睐，但历史上它却是一个著名的“反模式”。掌握Java单例模式双重检查锁DCL正确写法，其核心价值在于深刻理解Java内存模型（JMM）中指令重排序、内存可见性与`synchronized`、`volatile`关键字的协同工作原理，从而写出真正线程安全且高效的单例，避免因对并发底层原理的误解而引入难以追踪的隐蔽bug。本文将从一个错误示例出发，剖析其根源，最终给出经过验证的正确方案。
一、 目标与挑战：为何需要DCL？
单例模式要求一个类在JVM中只有一个实例，并提供全局访问点。实现它有几个核心要求：线程安全、延迟加载（Lazy Loading）、高性能。
最简单的实现是直接在类加载时就创建实例（饿汉式），但这失去了延迟加载的优势。而最简单的延迟加载（在`getInstance()`方法上加`synchronized`）又会导致每次调用都同步，性能堪忧。DCL的目标正是在首次创建实例时进行同步，后续所有调用都能无锁地返回已创建好的实例，完美平衡了延迟加载与性能。然而，实现这一目标的道路布满陷阱。
二、 经典错误写法与其隐蔽危害
我们先看一个流传甚广但**完全错误**的DCL实现：
public class Singleton {
private static Singleton instance; // 错误根源：缺少 volatile 修饰
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) { // 第一次检查（无锁）
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查（持有锁）
instance = new Singleton(); // 问题出在这一行！
}
}
}
return instance;
}
}
这个操作并非原子操作，它大致包含三个JVM指令： 1. `memory = allocate();` // 1. 为对象分配内存空间 2. `ctorInstance(memory);` // 2. 初始化对象（调用构造函数） 3. `instance = memory;` // 3. 将内存地址赋值给引用变量
关键在于，JVM可能出于优化目的，对步骤2和步骤3进行指令重排序。重排序后的执行顺序可能是1->3->2。考虑如下并发场景： - 线程A进入同步块，执行`new Singleton()`，发生了重排序（1，3，2）。此时`instance`已不为null，但指向的对象**尚未被初始化**（步骤2未执行）。 - 线程B执行第一次检查`if (instance == null)`，发现`instance`不为null（线程A已执行步骤3），于是直接返回这个尚未初始化完毕的“半成品”对象。 - 线程B使用这个不完整的对象，可能导致程序行为异常或崩溃。
这个错误极其隐蔽，因为在大多数测试中难以复现，但它像一颗定时炸弹埋在代码中。在鳄鱼java的代码审计历史上，这种错误写法是高频发现项。
三、 根本原因：Java内存模型与指令重排序
要理解为何上述写法错误，以及如何修正，必须深入Java内存模型（JMM）。JMM规定，为了性能，编译器和处理器可以对指令进行重排序，但必须遵守as-if-serial语义（单线程执行结果不能被改变）。然而，多线程环境下，重排序可能导致其他线程观察到与程序顺序不一致的内存状态。
在错误示例中，对于线程A，`new Singleton()`内部的指令重排序不会影响它自身的执行结果。但对于线程B，它却“看到”了一个出乎意料的状态。`synchronized`可以保证同一时刻只有一个线程执行同步块，并确保锁释放前会将工作内存的修改刷新到主内存，但它不能禁止同步块内部的指令重排序。
这就是为什么一个看似完美的Java单例模式双重检查锁DCL正确写法必须解决指令重排序问题。
四、 正确实现：volatile的关键作用
解决方案是使用`volatile`关键字修饰`instance`变量。这是唯一正确的Java单例模式双重检查锁DCL正确写法。
public class Singleton {
// 关键：使用 volatile 修饰
private static volatile Singleton instance;
private Singleton() {
// 防止反射攻击
if (instance != null) {
throw new RuntimeException(“禁止通过反射创建单例”);
}
}
public static Singleton getInstance() {
// 第一次检查：避免大多数情况下的同步开销
if (instance == null) {
synchronized (Singleton.class) {
// 第二次检查：防止首次创建时的竞争
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
`volatile`在此处做了两件至关重要的事： 1. 禁止指令重排序：通过插入内存屏障（Memory Barrier），确保`instance = new Singleton();`这行代码中，对象的初始化操作（步骤2）一定在对引用赋值操作（步骤3）之前完成。这解决了“半初始化”问题。 2. 保证内存可见性：当线程A在同步块内完成对`instance`的写入后，由于`volatile`的写语义，会立即将修改刷新到主内存。当线程B执行第一次无锁读取时，由于`volatile`的读语义，会强制从主内存重新加载变量值，从而看到线程A创建完成的完整对象。
因此，`volatile`是修复DCL缺陷的必要且充分条件。没有它，DCL就是不安全的。
五、 对比与演进：其他单例实现方案
理解了DCL，我们将其放在更广阔的单例实现谱系中审视：
| 实现方式 | 线程安全 | 延迟加载 | 性能 | 实现难度 | 备注 |
|---|---|---|---|---|---|
| 饿汉式（静态常量） | 是 | 否 | 高 | 低 | 最简单，无锁，类加载时即初始化。可能造成资源浪费。 |
| 懒汉式（方法同步） | 是 | 是 | 低（每次调用都同步） | 低 | 不推荐用于性能敏感场景。 |
| DCL（正确volatile版） | 是 | 是 | 高（首次后无锁） | 中 | 本文核心，平衡了延迟与性能。 |
| 静态内部类（Holder） | 是 | 是 | 高 | 低 | 利用类加载机制保证线程安全，无需同步，推荐。 |
| 枚举（Enum） | 是 | 否（本质是饿汉式） | 高 | 低 | 《Effective Java》作者推荐，防反射和反序列化攻击。 |
静态内部类实现示例（作为DCL的优秀替代）：
public class Singleton {
private Singleton() {}
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE; // 首次调用时加载内部类并初始化INSTANCE
}
}
六、 总结：超越写法，理解本质
探索Java单例模式双重检查锁DCL正确写法的旅程，远不止于记住`volatile`这个关键字。它是一次深入Java并发内存模型核心的绝佳实践。它教会我们，在并发编程中，仅凭代码逻辑的正确性是不够的，必须考虑底层的内存可见性和指令执行顺序。
在鳄鱼java的工程师培养体系中，DCL是一个经典的教学案例，用于考察候选人对JMM的理解深度。它清晰地展示了理论知识（JMM）如何直接指导并修正实践代码。
现在，请回顾你或你团队项目中的代码：是否存在看似正确实则危险的DCL实现？当你在选择单例实现方案时，是习惯性地复制一段旧代码，还是会根据场景（是否需要严格延迟加载、是否面临反射攻击风险）在枚举、静态内部类和DCL之间做出有意识的选择？记住，对工具和模式的理解深度，决定了你构建的系统在极端情况下的健壮性。从今天起，让你的单例不仅“能用”，而且“可靠”。
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
