如何利用 Java 指令重排现象理解单例模式中双重检查锁（DCL）必须加 volatile 的原因

如何利用 Ja va 指令重排现象理解单例模式中双重检查锁（DCL）必须加 volatile 的原因

DCL单例中必须用volatile，因为它禁止指令重排序（防止初始化与引用赋值乱序）并保证可见性（使新实例对其他线程立即可见），缺一不可，否则可能返回半初始化对象。

instance = new Singleton() 不是原子操作

这里有个常见的误解：很多人觉得 instance = new Singleton() 就是一条“创建对象并赋值”的简单语句，一步到位。但实际上，在JVM底层，这条语句至少会被拆解成三个关键步骤：首先分配内存空间，接着调用构造函数进行初始化，最后才把对象的引用写入静态变量。在单线程环境下，这三步看起来是按部就班执行的，一切都很美好。然而，为了追求极致的性能，编译器或CPU可能会在背后悄悄调整“初始化”和“赋值”这两步的顺序——这就是所谓的指令重排序。结果就是，instance 可能已经指向了一块内存地址，但对象内部的字段还没来得及被构造函数设置好。

没有 volatile 时，其他线程可能拿到半初始化对象

让我们设想一个典型的并发场景。假设线程A正在创建单例，并且不幸（或者说，在优化策略下）遭遇了重排序：内存分配好了，引用也立刻赋值给了 instance（此时它已非null），但构造函数初始化这一步却被排到了后面，还没来得及执行。就在这个微妙的间隙，线程B闯入了 getInstance() 方法。它进行第一次检查，发现 instance != null，于是欢天喜地地直接返回了这个引用。悲剧就此发生：线程B拿到的对象，其内部字段全是默认值（比如int字段是0，对象引用字段是null）。一旦线程B试图使用这些字段，NullPointerException 或者更隐蔽的逻辑错误就会瞬间爆发。

• 需要明确的是，synchronized 关键字只能保证它包裹的临界区内的操作具有有序性和可见性。但对于临界区之外的读操作——比如DCL中第一次的 if (instance == null) 检查——它不提供任何保证。
• volatile 在这里扮演的角色，并非粗暴地“禁止所有重排”，而是通过插入特定的内存屏障，强制实现一个关键规则：“初始化完成”这个操作必须发生在“引用赋值”之前。
• 即便在JDK 5及之后强化了的Ja va内存模型（JMM）中，DCL模式已经被官方认可，但不加 volatile 的写法依然是未定义行为。现代的JIT编译器仍然可能进行一些危险的优化，导致问题重现。

volatile 的两个关键作用不可替代

那么，只用 synchronized 行不行？答案是否定的。因为问题的症结恰恰出现在同步块之外的那次读操作上。要堵上这个漏洞，必须依赖 volatile 同时提供的两种保障：

• 可见性：确保当一个线程成功写入 instance 后，这个新值能立刻对其他所有线程变得可见，大家看到的都是同一个完整的对象。
• 禁止特定重排序：阻止JVM将构造函数的执行步骤与将引用赋值给变量的步骤进行乱序，从根源上杜绝“半成品”对象的流出。

这两个作用，就像一把锁的两道保险，缺了任何一道，双重检查锁在高并发场景下都可能失效，返回一个未完全构造好的对象。

立即学习“Ja va免费学习笔记（深入）”；

别信“我本地测试没出问题”

最后，必须警惕一种侥幸心理：“我测试了成千上万次都没事”。指令重排序是否发生、何时发生，取决于一系列复杂且动态的因素：JIT编译的时机、CPU的具体架构、系统的实时运行负载，甚至垃圾回收的状态。你的测试环境可能永远无法触发那个特定的条件组合，但代码一旦上线，在某种高压力或特定的硬件环境下，问题就可能突然暴露。这并非小概率事件，而是触发条件极其隐蔽。真正的风险，往往就潜伏在那些看似“从未出错”的代码深处。