不加 volatile 会导致其他线程看到未初始化完成的单例对象，引发 NullPointerException 或逻辑错误；因为 JVM 可能重排序对象创建的三步（分配内存→赋值引用→初始化），使 instance 非空但字段仍为默认值，而 volatile 能禁止重排序并保证可见性。
因为不加 volatile 会导致其他线程看到一个“已分配内存但未初始化完成”的单例对象，从而引发 NullPointerException 或逻辑错误——这不是概率问题，而是在 JDK 5 之后仍可能发生的确定性风险。
对象创建不是原子操作
语句 instance = new Singleton() 实际被 JVM 拆成三步：
- 分配内存空间（memory = allocate()）
- 调用构造函数初始化对象（ctorInstance(memory)）
- 将引用赋值给静态变量（instance = memory）
在没有 volatile 时，JVM 和 CPU 可能对第 2 步和第 3 步重排序：先完成内存分配 + 引用赋值，再执行构造初始化。此时 instance != null 为真，但对象内部字段仍是默认值（如 null、0、false）。
synchronized 只保临界区，不保外层可见性
双重检查锁中，外层 if (instance == null) 是非同步的。虽然内层 synchronized 块能保证其内部的原子性和有序性，但它无法让这个“赋值完成”的结果**及时、可靠地通知到其他线程**。其他线程可能从自己的工作内存中读到过期的 instance 值，或读到已被写入但尚未初始化完毕的引用。
volatile 在这里起两个关键作用：
- 禁止
instance的写操作与构造初始化之间的指令重排序 - 确保一旦一个线程写入了
instance，其他线程读取时一定能看见最新值（即强制从主内存读）
不加 volatile 的典型并发场景
假设有线程 A 和线程 B 同时调用 getInstance()：
- 线程 A 进入同步块，执行到
instance = new Singleton()，JVM 重排为：分配内存 → 赋值引用 → 初始化 - 赋值完成后，
instance已不为null，线程 A 尚未完成初始化就释放锁 - 线程 B 此时执行外层判断：
if (instance == null)→ 结果为false，直接返回instance - 线程 B 拿到的是一个半初始化对象，后续调用其方法时可能因字段为
null或未计算状态而崩溃
替代方案更推荐，但理解 volatile 不可少
虽然枚举单例或静态内部类方式更简洁安全（天然防重排、无需 volatile），但双重检查锁仍是理解 Java 内存模型（JMM）、可见性与重排序的经典入口。只要选择 DCL，volatile 就是强制要求，不是优化选项。
