必须加volatile，否则dcl单例可能返回未初始化对象；因instance = new singleton()被拆为分配内存、初始化、赋值三步，jvm/cpu可能重排为分配→赋值→初始化，导致其他线程看到非null但未初始化的实例。
必须加 volatile，否则 DCL 单例在多线程下可能返回未初始化的对象。
为什么 instance = new Singleton() 不是原子操作
这行代码在 JVM 底层被拆解为三个独立步骤：
- 分配内存空间（
allocate()） - 调用构造方法初始化对象（
ctorInstance()） - 将引用赋值给静态变量（
instance = memory）
其中第 2 步和第 3 步没有数据依赖，JVM 或 CPU 可能重排为「分配 → 赋值 → 初始化」。此时 instance 已非 null，但对象字段仍是默认值（如 int 为 0、引用为 null）。
不加 volatile 时的典型翻车场景
假设线程 A 执行创建，发生重排序后刚完成「赋值」就切出；线程 B 紧接着调用 getInstance()：
- 线程 B 进入第一次
if (instance != null)，发现不为空，直接返回 - 线程 B 使用该实例调用方法或访问字段，结果读到未初始化的值，比如
NullPointerException或0 - 这个错误不依赖高并发压测，只要多核 CPU + JDK 5+ + 非空构造逻辑，就可能偶发
volatile 到底拦住了什么
它不保证原子性，也不参与加锁逻辑，只做两件事：
- 禁止写操作前后的指令重排序：确保「初始化」一定在「赋值」之前完成
- 强制主内存可见性：其他线程读到非空
instance时，一定能看见完整的初始化结果
本质上，volatile 在赋值前后插入内存屏障（StoreStore 和 LoadLoad），把松散的三步“钉死”为严格顺序：分配 → 初始化 → 赋值。
synchronized 为什么拦不住第一次检查
synchronized 只能保证临界区内的语句串行执行，但它对临界区外的读操作（即第一次 if 检查）没有约束力。而重排序产生的「半初始化引用」恰恰在锁外就被其他线程看到了——volatile 正是补上这个缺口的关键一环。
