volatile通过插入内存屏障禁止instance引用赋值与对象初始化之间的指令重排，确保其他线程读取时看到的是完全初始化的对象，从而修复双重检查锁中“半成品”对象问题。
为什么 instance = new Singleton() 不是原子操作
Java 中的 new Singleton() 实际拆解为三步：1）分配内存；2）调用构造器初始化对象；3）将引用赋值给 instance 变量。这三步在单线程下语义等价，JVM 和 CPU 会按需重排——只要不破坏数据依赖（比如第2步必须在第1步之后），第2步和第3步就可能被交换成 1→3→2。
一旦发生 1→3→2 重排，instance 就提前非空了，但对象内部字段还没初始化完毕。此时另一个线程刚好执行第一次 if (instance == null) 判断，会直接返回这个“半成品”引用，后续调用其方法大概率抛 NullPointerException 或读到默认值（如 int 字段为 0 而非预期值）。
双重检查锁里 synchronized 为什么拦不住重排
synchronized 只能保证临界区内的操作串行、可见性（通过锁释放时刷主存），但它对锁外的读写没有约束力。第一次 if (instance == null) 是在锁外执行的，而重排发生在 instance = new Singleton() 这条语句内部——它属于锁内，但 JVM 允许把其中的“赋值”动作提前到“初始化”之前，只要不违反单线程语义。
也就是说：synchronized 解决了“多个线程不会同时执行构造逻辑”，但没解决“构造逻辑自身被拆开并乱序执行”的问题。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 锁能防止多线程重复创建实例
- 锁不能阻止构造过程中的指令重排
- 锁外的快速判空依赖的是
instance的“及时、完整”状态，而这正是重排破坏的
volatile 怎么堵住这个漏洞
volatile 在写操作（即 instance = new Singleton() 完成那一刻）后插入写屏障（Store Barrier），强制要求：所有对该对象的初始化操作（即第2步）必须在写屏障之前完成；在读操作（即 if (instance == null)）前插入读屏障（Load Barrier），确保读到的是写屏障之后的最新值。
效果上，它让 JVM 把 new 拆解的三步变成“不可分割的原子发布”——要么全没发生，要么全部完成且对其他线程可见。
- 禁止
instance引用写入与构造初始化之间的重排（关键） - 保证其他线程读取
instance时，能立即看到已完全初始化的对象 - 不加
volatile的 DCL 在 JDK 5 之前是错误的；JDK 5+ 的 JMM 明确赋予volatile这一语义
不加 volatile 的典型错误现象
这种 bug 很难复现，往往只在高并发、特定 CPU 架构（如 ARM）、JIT 优化开启时偶然触发，表现为：
- 某个线程拿到
instance后调用其方法，抛出NullPointerException - 对象字段值为默认值（如
String字段为null，int为 0），而非构造器中设置的值 - 日志显示 “instance != null” 但对象行为异常，且无法稳定断点复现
真正麻烦的不是写错，而是错得悄无声息——它可能在线上跑几个月才偶发一次，而堆栈里看不出任何同步或初始化失败痕迹。
