Double-Checked Locking 中的 instance = new Singleton() 为什么不是原子操作
很多人以为 new Singleton() 就是“创建一个对象”，但 JVM 实际执行时拆成三步：分配内存 → 调用构造函数初始化字段 → 将引用赋值给 instance 变量。这三步在单线程下顺序执行没问题，但在多线程+JIT优化下，第2步和第3步可能被重排序为 分配内存 → 赋值引用 → 初始化字段。
后果是：线程A刚执行完第3步（instance 已非 null），线程B立刻进入第一次检查，发现 instance != null，直接返回——此时对象字段还没初始化（比如 int i = 9 还是默认值 0），甚至构造函数里的逻辑根本没跑。
为什么加 synchronized 块仍不能阻止这个问题
synchronized 能保证临界区的互斥和可见性，但它不约束块内语句的指令重排。也就是说，synchronized 块里那行 instance = new Singleton() 依然可能被重排——只要重排不破坏本线程的 as-if-serial 语义，JVM 就允许。
所以只靠 synchronized 锁住第二次检查，无法防止“引用提前发布”（early publication）问题。这也是 Java 5 之前 DCL 被官方宣布为“broken”的根本原因。
volatile 如何修复重排漏洞
volatile 在这里起两个关键作用：
- 禁止写操作（即
instance的赋值）与它之前的初始化操作重排序 —— 确保构造函数执行完，才允许把引用写出去 - 建立 happens-before 关系：对
volatile变量的写，happens-before 任意后续对该变量的读
因此必须声明为：private static volatile Singleton instance;。漏掉 volatile，哪怕其他都对，DCL 在高并发下仍可能返回半初始化对象。
常见误写与静态内部类替代方案的对比
有人会写成这样：
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
Singleton temp = new Singleton(); // 临时变量无意义
instance = temp;
}
}
}
return instance;
}
这种写法无效 —— temp 不改变 instance 的可见性或重排约束。
如果你不想碰 volatile 和同步块，static inner class 是更简洁安全的选择：
private static class Holder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}
JVM 保证类初始化是线程安全且不可重排的，且 Holder 类只在首次调用 getInstance() 时才加载 —— 懒汉 + 天然线程安全，无须 volatile 或 synchronized。
真正容易被忽略的点是：DCL 的正确性极度依赖 volatile 的内存语义，而不是锁本身；而很多线上项目至今还在用没加 volatile 的版本，出问题往往表现为偶发空指针、字段值异常，极难复现和定位。
