volatile 在 dcl 单例中起禁止重排序和保证可见性双重作用，防止对象半初始化：jvm 将 new singleton() 拆为分配内存、调用构造器、赋值引用三步，无 volatile 时②③可能重排导致其他线程拿到未初始化完成的对象；volatile 插入写屏障确保构造完成后再赋值，并强制主内存读写，使初始化结果对所有线程立即可见。
volatile 在 DCL 单例中起的是「禁止重排序 + 保证可见性」双重作用，直接堵住对象半初始化漏洞。
对象创建不是原子操作，三步可能被重排
写 `instance = new Singleton()` 看似一行代码，JVM 实际拆成三步：
- 在堆中分配内存空间
- 调用构造方法初始化对象（比如给字段赋值）
- 将引用赋值给 static 变量 instance
其中第②③步在没有约束时可能被 CPU 或 JIT 编译器重排序：先执行①③，再执行②。结果就是 instance 已非 null，但对象内部字段仍是默认值或未初始化状态。另一个线程拿到这个“壳子”，一访问字段就抛 NullPointerException。
volatile 阻断重排序，锁住发布顺序
加了 volatile 后，JVM 会在写 instance 这个变量时插入写屏障（write barrier），强制要求：
- 构造方法中的所有初始化操作（②）必须在赋值操作（③）之前完成
- 不允许把③提到②前面，彻底杜绝“引用先发布、内容后填充”的情况
这就确保了：只要其他线程看到 instance != null，那它一定是一个完全构造好的实例。
volatile 还让初始化结果对所有线程立即可见
没有 volatile 时，线程 A 在同步块内完成了初始化并写入 instance，但该写入可能还停留在本地 CPU 缓存中，线程 B 读到的仍是旧值（null 或过期值）。volatile 强制每次读写都直连主内存，保证：
- 线程 A 写完 instance 后，其他线程能立刻读到非 null 值
- 且这个读操作还能顺带看到 A 在写 instance 之前做过的所有内存写入（如对象字段的赋值）
这就是所谓的“happens-before”语义——volatile 写 happens-before 后续任意线程的 volatile 读。
只靠 synchronized 不够，必须配 volatile
synchronized 能保证临界区内的操作串行执行，也能提供内存可见性，但它只对加锁期间的操作生效。而 DCL 的外层判空（`if (instance == null)`）是不加锁的——这行代码如果读到一个被重排序发布的半初始化引用，synchronized 根本来不及干预。volatile 正是守在这道“第一道门”上的关键防线，把问题拦在进入同步块之前。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
