登录
首页 >  文章 >  java教程

Double-CheckedLocking模式详解

时间:2026-05-08 10:39:43 206浏览 收藏

Double-Checked Locking(DCL)看似精巧的单例实现,实则暗藏致命陷阱:由于JVM指令重排序,未加volatile修饰的instance = new Singleton()可能将引用赋值提前于对象初始化完成,导致其他线程获取到半初始化、字段为默认值甚至构造逻辑未执行的“幽灵对象”,引发偶发性空指针或数据异常——这种问题极难复现和调试;而单纯加synchronized并不能阻止块内重排,真正起决定性作用的是volatile提供的禁止重排序与happens-before语义;若追求简洁可靠,静态内部类方案凭借JVM类加载机制的天然线程安全与懒加载特性,反而是更优、更不易出错的选择。

如何通过 Double-Checked Locking 模式理解内存模型中指令重排对单例的影响

Double-Checked Locking 中的 instance = new Singleton() 为什么不是原子操作

很多人以为 new Singleton() 就是“创建一个对象”,但 JVM 实际执行时拆成三步:分配内存调用构造函数初始化字段将引用赋值给 instance 变量。这三步在单线程下顺序执行没问题,但在多线程+JIT优化下,第2步和第3步可能被重排序为 分配内存 → 赋值引用 → 初始化字段

后果是:线程A刚执行完第3步(instance 已非 null),线程B立刻进入第一次检查,发现 instance != null,直接返回——此时对象字段还没初始化(比如 int i = 9 还是默认值 0),甚至构造函数里的逻辑根本没跑。

为什么加 synchronized 块仍不能阻止这个问题

synchronized 能保证临界区的互斥和可见性,但它不约束块内语句的指令重排。也就是说,synchronized 块里那行 instance = new Singleton() 依然可能被重排——只要重排不破坏本线程的 as-if-serial 语义,JVM 就允许。

所以只靠 synchronized 锁住第二次检查,无法防止“引用提前发布”(early publication)问题。这也是 Java 5 之前 DCL 被官方宣布为“broken”的根本原因。

volatile 如何修复重排漏洞

volatile 在这里起两个关键作用:

  • 禁止写操作(即 instance 的赋值)与它之前的初始化操作重排序 —— 确保构造函数执行完,才允许把引用写出去
  • 建立 happens-before 关系:对 volatile 变量的写,happens-before 任意后续对该变量的读

因此必须声明为:private static volatile Singleton instance;。漏掉 volatile,哪怕其他都对,DCL 在高并发下仍可能返回半初始化对象。

常见误写与静态内部类替代方案的对比

有人会写成这样:

private static Singleton instance;
public static Singleton getInstance() {
    if (instance == null) {
        synchronized (Singleton.class) {
            if (instance == null) {
                Singleton temp = new Singleton(); // 临时变量无意义
                instance = temp;
            }
        }
    }
    return instance;
}

这种写法无效 —— temp 不改变 instance 的可见性或重排约束。

如果你不想碰 volatile 和同步块,static inner class 是更简洁安全的选择:

private static class Holder {
    private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
    return Holder.INSTANCE;
}

JVM 保证类初始化是线程安全且不可重排的,且 Holder 类只在首次调用 getInstance() 时才加载 —— 懒汉 + 天然线程安全,无须 volatilesynchronized

真正容易被忽略的点是:DCL 的正确性极度依赖 volatile 的内存语义,而不是锁本身;而很多线上项目至今还在用没加 volatile 的版本,出问题往往表现为偶发空指针、字段值异常,极难复现和定位。

终于介绍完啦!小伙伴们,这篇关于《Double-CheckedLocking模式详解》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识,快来关注吧!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>