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

DCL单例看似巧妙，实则暗藏并发陷阱：不加volatile修饰的instance字段会因JVM和CPU的指令重排序，导致其他线程在看到非null引用的同时读取到未初始化完成的对象，引发NullPointerException或字段为默认值等诡异问题；虽然synchronized能保证临界区互斥，却无法建立跨线程的happens-before关系，唯有volatile才能同时禁止重排序并确保可见性——但即便写对了volatile，DCL仍属高风险方案，性能优势有限、调试困难、环境兼容性差，远不如静态内部类（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 模型推演

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~