dcl单例中必须用volatile，因为它禁止指令重排序（防止初始化与引用赋值乱序）并保证可见性（使新实例对其他线程立即可见），缺一不可，否则可能返回半初始化对象。
instance = new Singleton() 不是原子操作
很多人误以为 instance = new Singleton() 就是一条“创建对象并赋值”的简单语句，实际上 JVM 会把它拆成至少三步：分配内存、调用构造函数初始化、把引用写入静态变量。这三步在单线程里看似顺序执行，但编译器或 CPU 为优化性能，可能把“初始化”和“赋值”顺序调换——也就是先让 instance 指向一块已分配但尚未初始化的内存地址。
没有 volatile 时，其他线程可能拿到半初始化对象
假设线程 A 执行到重排序后的步骤：分配内存 → 赋值（instance 已非 null）→ 初始化（还没开始）。此时线程 B 进入 getInstance()，第一次检查发现 instance != null，直接返回这个引用。而该对象的字段仍为默认值（如 int 是 0、Object 是 null），一旦线程 B 访问其成员，就会触发 NullPointerException 或逻辑错误。
-
synchronized只能保证临界区内的有序性和可见性，但对临界区外的读操作（比如第一次if (instance == null)）不提供任何保证 -
volatile在这里不是为了“禁止所有重排”，而是插入内存屏障，强制“初始化完成” happens-before “引用赋值” - 即使 JDK 5+ 之后的内存模型已明确支持 DCL，不加
volatile仍是未定义行为，JIT 编译器仍可能做危险优化
volatile 的两个关键作用不可替代
仅靠 synchronized 解决不了这个问题，因为问题出在同步块之外的读操作上。必须用 volatile 同时满足：
- 可见性：确保一个线程写入
instance后，其他线程能立刻看到非 null 值 - 禁止重排序：阻止 JVM 把构造函数执行（第二步）和引用赋值（第三步）乱序
这两个作用缺一不可；去掉任意一个，DCL 在高并发下就可能返回未完全构造的对象。
别信“我本地测试没出问题”
指令重排是否发生、何时发生，取决于 JIT 编译时机、CPU 架构、运行负载甚至 GC 状态。你写的测试可能跑一万次都正常，但上线后在某个特定压力场景下突然崩溃——而且很难复现。这不是概率低，而是触发条件隐蔽。真正的问题往往藏在那些“从来没出过错”的代码里。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
