DPL单例模式：并发安全解析

DPL单例模式中，双重检查锁定（DCL）若未将instance字段声明为volatile，即便加了synchronized也无法保证线程安全——因JVM和CPU的指令重排序可能导致其他线程看到半初始化的对象，引发NullPointerException或字段值为默认值等隐蔽崩溃；volatile不仅是“锦上添花”，而是建立happens-before关系、禁止重排序与保障可见性的唯一低成本关键保障，但因其易错难测、维护成本高，实际开发中更推荐语义清晰、天然线程安全的静态内部类（Holder）模式或枚举单例，真正棘手的从来不是代码怎么写，而是那个常被忽略的volatile背后所承载的Java内存模型深层约束。

双重检查锁定（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 模型推演

真正麻烦的从来不是写几行代码，而是忘记那个 volatile 关键字，以及它背后那条看不见的 happens-before 边。

以上就是《DPL单例模式：并发安全解析》的详细内容，更多关于的资料请关注golang学习网公众号！