DCL懒加载必须加volatile才能线程安全，因其禁止new对象时的指令重排序（1→3→2），确保instance不为null时对象必已初始化；synchronized只保构建原子性，volatile才保初始化完成的可见性与顺序性。
在并发环境下实现懒加载，双重检查锁（DCL）本身不能保证线程安全——volatile 是补全其安全性的必要一环，缺它就会出现“对象已分配但未初始化”的诡异状态。
为什么 DCL 会失效？根源是 JVM 指令重排序
看似简单的一行 instance = new Singleton()，JVM 实际拆解为三步：
- 为对象分配内存空间
- 调用构造方法初始化字段（如设置属性、执行逻辑）
- 将引用赋值给静态变量
instance
在无同步保障时，JVM 和 CPU 可能将第2步和第3步重排序为：1 → 3 → 2。也就是说，instance 已指向一块内存地址，但该内存中对象字段仍是默认值（如 null、0、false）。
此时另一个线程执行第一次判空：if (instance != null)，结果为 true，直接返回这个“半成品”对象——后续调用其方法或字段，大概率触发 NullPointerException 或逻辑错乱。
volatile 如何堵住这个漏洞？两个语义同时生效
可见性：确保一个线程对 instance 的写操作，对其他线程立即可见。避免因 CPU 缓存不一致导致线程读到旧值（null）而重复创建。
禁止重排序：这是关键。volatile 写操作具有“内存屏障”效果，强制编译器和处理器禁止在其前后发生特定重排。具体到 DCL 场景，它禁止“new 对象后赋值引用”这一写操作与构造函数中的初始化操作重排序，从而保证：只要 instance 不为 null，它所指向的对象一定已完成初始化。
不加 volatile 的 DCL 是伪线程安全
很多人误以为 synchronized 块内已经加锁，外面的判空就足够安全。但问题恰恰出在 synchronized 块之外：
- 第一次判空发生在锁外，是性能优化的关键，但也成了重排序暴露的窗口
- synchronized 只能保证块内操作的原子性和可见性，无法约束锁外的读操作与锁内写操作之间的指令顺序
- 没有 volatile，JMM 不提供跨线程的初始化完成保证——即“写后读”的 happens-before 关系不成立
换句话说，synchronized 解决了“谁来建”，volatile 才确保“建完再用”。两者配合，才是工业级懒加载的完整闭环。
正确写法：volatile + DCL 缺一不可
标准单例实现应为：
public class Singleton {
private static volatile Singleton instance; // ← 必须 volatile
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) { // 第一次检查（无锁）
synchronized (Singleton.class) {
if (instance == null) { // 第二次检查（有锁）
instance = new Singleton(); // ← volatile 保障此处安全
}
}
}
return instance;
}
}
这里 volatile 不是锦上添花，而是把 DCL 从“大概率可用”拉回“严格正确”的临门一脚。
