Java中实现线程安全单例模式的方案有很多，双重检查锁定（Double-Checked Locking）是其中一种兼顾性能和线程安全的常见实现方式，但是很多开发者在初次实现时容易忽略volatile关键字的作用，导致单例在多线程环境下出现不可预期的问题。
双重检查锁定的基础实现
我们先来看一个没有使用volatile修饰的典型双重检查锁定单例代码：
public class Singleton {
// 未加volatile修饰的单例实例
private static Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
// 第一次检查，避免不必要的同步
if (instance == null) {
synchronized (Singleton.class) {
// 第二次检查，确保只有一个实例被创建
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
这段代码看起来逻辑上很严谨，第一次判空避免了大多数情况下进入同步块的开销，同步块保证了同一时间只有一个线程能执行实例创建逻辑，第二次判空保证了实例不会被重复创建。但实际上这个实现在多线程环境下是存在线程安全风险的。
指令重排序带来的问题
问题的根源在于instance = new Singleton();这行代码并不是一个原子操作，它在JVM中会被拆分为三个步骤执行：
- 1. 为Singleton对象分配内存空间
- 2. 初始化Singleton对象的各个字段，调用构造方法
- 3. 将instance引用指向分配好的内存地址
而JVM为了优化执行效率，可能会对这三个步骤进行指令重排序，步骤2和步骤3的执行顺序可能被调换，变成先执行步骤3，再执行步骤2。这种情况下，线程A执行到步骤3时，instance已经不为null了，但是此时Singleton对象还没有完成初始化。
如果这时候线程B执行getInstance()方法，第一次检查会发现instance != null，就会直接返回这个还没有完成初始化的instance实例，后续使用这个实例就可能出现空指针等异常问题，导致线程安全被破坏。
volatile如何解决这个问题
volatile关键字有两个核心作用：一是保证变量的可见性，一个线程修改了volatile变量的值，其他线程能立刻感知到最新值；二是禁止指令重排序，被volatile修饰的变量的读写操作前后的指令不会被重排序。
当我们把instance变量用volatile修饰后，instance = new Singleton();这三个步骤的重排序就会被禁止，一定是先完成对象初始化，再将引用指向内存地址，这样其他线程在获取到instance的时候，一定能拿到完全初始化完成的对象。
正确的双重检查锁定单例实现代码如下：
public class Singleton {
// 用volatile修饰单例实例，禁止指令重排序
private static volatile Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
// 第一次检查，避免不必要的同步
if (instance == null) {
synchronized (Singleton.class) {
// 第二次检查，确保只有一个实例被创建
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
为什么不用其他方案替代
可能有人会问，既然双重检查锁定这么容易出问题，为什么不直接用其他单例实现方式？比如静态内部类单例或者枚举单例。实际上双重检查锁定的优势在于它的延迟加载特性，同时只有在第一次创建实例的时候才会进入同步块，后续获取实例的开销非常小，在对性能要求较高的场景下还是很有使用价值的，只要配合volatile正确使用，就能同时兼顾性能和线程安全。
需要注意的是，volatile只能禁止它修饰的变量的读写操作相关的指令重排序，不能禁止所有指令的重排序，所以这里必须精准修饰instance变量才能生效。如果开发者在写双重检查锁定单例时遗漏了volatile，就相当于给程序埋下了一个隐蔽的线程安全隐患，在高并发场景下可能很久才会暴露问题，排查起来难度很大。
Double_Checked_Lockingvolatile线程安全单例Java修改时间：2026-07-04 01:54:23