Java双重检查锁定实现单例安全机制

Java中使用双重检查锁定（DCL）实现单例时，若未将instance字段声明为volatile，即便加了synchronized也无法保证线程安全——因为对象构造的指令重排序可能导致其他线程拿到一个已分配内存但尚未完成初始化的“半成品”实例，进而引发NullPointerException或字段值为默认值等隐蔽崩溃；volatile不仅禁止重排序，更关键的是建立happens-before关系，确保构造完成后的所有写操作对后续读线程可见；尽管DCL在高并发场景下有一定性能优势，但极易因遗漏volatile而埋下线上隐患，且维护成本高、测试难覆盖，因此更推荐语义清晰、零配置、天然线程安全的静态内部类（Holder模式）或枚举单例方案。

双重检查锁定（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。

• 典型错误现象：getInstance() 返回非 null，但调用 instance.doWork() 报 NullPointerException（因为 doWork 依赖的字段还没初始化完）
• IDEA 或 Checkstyle 可配置警告：非 volatile 的延迟初始化单例字段
• 单元测试很难覆盖该问题——需要精确控制指令重排和线程调度，基本靠压力测试或 JMM 模型推演

今天关于《Java双重检查锁定实现单例安全机制》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！