DCL单例不加volatile不是线程安全的，因对象构造可能被重排序，导致其他线程看到未初始化完成的实例；必须用volatile禁止重排序并保证可见性。
双重检查锁定（DCL）为什么不是线程安全的——除非加 volatile
不加 volatile 的 DCL 单例在 JDK 5 之前几乎必然出错，JDK 5 之后仍可能出错：对象构造可能被重排序，导致其他线程看到未初始化完成的实例。
-
new Singleton()分三步：分配内存 → 调用构造函数 → 将引用赋值给静态变量；JVM 和 CPU 都可能把第三步提前 - 没加
volatile时，instance != null判断可能为真，但内部字段仍是默认值（如int是 0、Object是null） - 仅靠
synchronized块内初始化不能阻止外部线程读到“半初始化”对象——缺少 happens-before 关系
正确写法：volatile 是必须项，不是可选项
只要用 DCL，instance 字段就必须声明为 volatile。这是唯一能禁止重排序 + 保证可见性的低成本方案。
- 错误写法：
private static Singleton instance; - 正确写法：
private static volatile Singleton instance; -
synchronized块仍需保留，否则多线程可能同时进入创建逻辑 - JDK 9+ 的
VarHandle或Unsafe可替代，但没必要——volatile已足够且语义清晰
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // 此处对 volatile 字段赋值，建立 happens-before
}
}
}
return instance;
}
DCL 比直接同步快，但比静态内部类/枚举慢且易错
DCL 的性能优势只在高并发 + 初始化后频繁调用的场景下才明显；实际项目中，它带来的维护成本远高于收益。
- 静态内部类方式（
Holder模式）无须volatile、无同步开销、天然线程安全，推荐优先使用 - 枚举单例最简最安全，但无法延时加载（类加载即初始化），且不支持懒汉式参数化构造
- DCL 在 Android（低版本 Dalvik）、某些 JIT 不稳定环境里仍偶发失效，日志难复现
常见误判：以为加了 synchronized 就万事大吉
很多开发者看到同步块就以为锁住了全部问题，结果线上偶发 NullPointerException 或字段为默认值，查半天发现是忘了 volatile。
立即学习“Java免费学习笔记（深入）”；
- 典型错误现象：
getInstance()返回非null，但调用instance.doWork()报NullPointerException（因为doWork依赖的字段还没初始化完） - IDEA 或 Checkstyle 可配置警告：非
volatile的延迟初始化单例字段 - 单元测试很难覆盖该问题——需要精确控制指令重排和线程调度，基本靠压力测试或 JMM 模型推演
volatile 关键字，以及它背后那条看不见的 happens-before 边。 
