什么是Java中的双重检查锁定_单例模式中的volatile与指令重排序防范-java教程-PHP中文网

双重检查锁不用volatile会出错，因jvm可能重排序对象构造步骤，导致其他线程看到未初始化完成的实例，引发nullpointerexception或字段为默认值；必须用volatile禁止重排序，且jdk 5+才真正支持。

什么是java中的双重检查锁定_单例模式中的volatile与指令重排序防范

为什么不用 `volatile` 的双重检查锁会出错

因为 JVM 可能对对象构造过程重排序，导致其他线程看到一个「已分配内存但未初始化完成」的实例。这不是多线程读写冲突，而是编译器和 CPU 对 new Singleton() 拆解后三步（分配内存 → 初始化 → 赋值给静态变量）的执行顺序不保证。

典型现象：某个线程调用 getInstance() 返回非 null，但后续访问其字段时抛 NullPointerException，或字段值为默认值（如 0、null）。

instance 字段必须声明为 volatile，否则无法禁止「初始化 → 赋值」之间的重排序
JDK 5+ 才真正支持 volatile 的禁止重排序语义；JDK 4 及之前即使写了也无效
仅加 synchronized 块不够——它只保同步块内有序，不约束同步块外的赋值可见性

双重检查锁的标准写法长什么样

核心是：volatile 修饰静态实例 + 两次 null 检查 + 同步块内再判空。漏掉任意一环都可能失效。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

public class Singleton {
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {                    // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {             // 第二次检查
                    instance = new Singleton();     // 这一行必须在 synchronized 内
                }
            }
        }
        return instance;
    }
}

instance 必须是 private static volatile，不能是 final（构造在运行时）
两个 if (instance == null) 缺一不可：第一个避免无谓同步，第二个防止多线程同时通过第一层后重复创建
new Singleton() 一定在 synchronized 块内部，且不能拆成两行（比如先声明变量再赋值）

什么情况下不该用双重检查锁

不是所有单例都适合——它解决的是「延迟初始化 + 高并发 + 无状态/轻构造」场景。一旦条件不满足，反而引入复杂性和风险。

构造函数耗时长（如加载配置、连数据库）：首次调用会阻塞所有后续线程，不如提前初始化（static 块）或用 Holder 模式
需要传参或依赖注入：双重检查锁无法支持构造参数，应改用 Spring 管理或显式工厂
类被反射或序列化破坏单例：volatile 不解决这个问题，得配合 readResolve() 或枚举
Android 环境下低版本（API volatile 语义支持不稳定，建议直接用静态内部类

Holder 模式比双重检查锁更简单可靠？

是的。它利用 Java 类加载机制的天然线程安全和懒加载，完全规避了重排序和同步问题，代码更短、可读性更高。

public class Singleton {
    private Singleton() {}

    private static class Holder {
        static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}