volatile的语义由jmm定义和保障，通过禁止重排序（锁住“先初始化再赋值”顺序）和保证可见性（建立happens-before关系），堵住dcl中对象半初始化暴露和线程间状态不可见两大漏洞。
Java 内存模型（JMM）在懒汉式单例中，不是“辅助”volatile，而是volatile 的语义完全由 JMM 定义和保障。它通过禁止重排序 + 强制可见性，堵住 DCL（双重检查锁）中两个关键漏洞：对象“半初始化”暴露、线程间状态不可见。
为什么没 volatile 就可能出问题？
看似简单的 instance = new Singleton()，JVM 实际会拆成三步：
- 1. 分配内存空间（给对象）
- 2. 初始化对象（调用构造器）
- 3. 将 instance 引用指向该内存地址
但 JMM 允许步骤 2 和 3 重排序——即先让 instance 指向一块已分配但尚未初始化完成的内存。此时若另一个线程恰好执行外层判空（instance != null），就会拿到一个“有引用、无内容”的对象，调用其方法大概率触发 NullPointerException 或未定义行为。
volatile 怎么靠 JMM 拦住这个漏洞？
volatile 在 JMM 中提供两条硬性约束：
- 禁止指令重排序：编译器和处理器不能把对 volatile 变量的写操作（即第 3 步）与它之前的初始化操作（第 2 步）重排序。这就锁死了“先初始化、再赋值”的顺序。
- 保证可见性：当一个线程写入 volatile 变量后，该写操作对其他线程立即可见；其他线程读取该变量时，必然看到最新值，且能同步看到该写操作之前所有已发生的内存操作结果（happens-before 关系）。
所以，加了 volatile 的 instance，既确保其他线程不会看到“构造中”的实例，也确保一旦看到非 null 的 instance，就一定能安全使用它的全部字段和方法。
光有 volatile 不够，为什么还得双重检查？
volatile 解决的是“写的安全”，但不解决“多线程同时进入创建逻辑”的竞争问题：
- 第一次判空（外层）不做同步，是为了避免每次调用都进锁，提升性能；
- 进锁后必须再次判空（内层），是因为多个线程可能同时通过外层检查，只允许其中一个真正创建实例；
- 而 volatile 保证了这个“唯一创建者”写完之后，其他线程能立刻、完整、正确地看到结果。
二者缺一不可：没有 volatile，DCL 会因重排序崩塌；没有双重检查，即使加了 volatile，仍可能创建多个实例。
补充：构造器里防反射攻击是额外加固
JMM 和 volatile 管不到反射。为防通过 Constructor.setAccessible(true) 绕过私有构造器新建实例，常在构造器中加入判断：
if (instance != null) throw new IllegalStateException();
这属于防御性编码，和 JMM 无关，但属于生产级单例的标配实践。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
