为什么Java单例模式一定要加volatile

江屿

发布时间：2026-10-16| 5人浏览过

原创

Java中的懒汉式单例模式通常需要结合synchronized和volatile来实现线程安全。尽管同步块保证了原子性，但volatile的作用在于禁止instance = new Singleton()这一过程的指令重排序，确保对象在完全初始化后再被引用。

1. 为什么要给单例变量加 volatile？

在面试或实际开发中，如果面试官询问“为什么单例模式一定要加 volatile”，其核心指向的是懒汉模式（Lazy Singleton）中私有静态对象的修饰。懒汉模式指的是对象采用延迟加载机制，即只在首次被真正使用时才进行创建，而非在应用启动时预加载。

下面是一个标准的、加了 volatile 的双检锁（Double-Checked Locking）单例实现：

public class Singleton {
    // 1. 私有构造方法，防止外部直接 new 破坏单例
    private Singleton() {}

    // 2. 定义静态实例，使用 volatile 修饰保证可见性和有序性
    private static volatile Singleton instance = null;

    // 3. 提供全局访问点
    public static Singleton getInstance() {
        if (instance == null) { // 第 1 次检查：无锁快速路径
            synchronized (Singleton.class) {
                if (instance == null) { // 第 2 次检查：锁定后再次检查
                    instance = new Singleton(); // 关键点
                }
            }
        }
        return instance;
    }
}

代码中使用了两次 if 判断配合 synchronized 锁机制，这已经确保了同一时刻只有一个线程能执行实例化操作。既然有锁保证了线程安全，为什么还需要加上一个 volatile 呢？要回答这个问题，必须先理解 volatile 的两个核心特性：

内存可见性（Visibility）
防止指令重排序（Ordering）

1.1 内存可见性问题

在多核或多线程环境下，每个线程通常拥有自己的本地缓存（如 CPU 的 L1/L2 缓存）。如果一个线程修改了共享变量的值并写入了主存，而其他线程可能仍然从自己的缓存中读取旧值，从而导致感知不到更新。这种现象就是内存可见性问题。

volatile 的引入强制线程对变量的读写都必须直接与主内存交互，从而解决了这一问题。为了演示这一现象，可以对比以下两组代码的执行结果：

场景 A：不使用 volatile

当共享标志位 flag 没有 volatile 修饰时：

private static boolean flag = false;
public static void main(String[] args) {
    Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            while (!flag) {
                // 空循环等待
            }
            System.out.println("终止执行");
        }
    });
    t1.start();

    Thread t2 = new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("设置 flag 变量的值为 true！");
            flag = true;
        }
    });
    t2.start();
}

图1：未加 volatile 时，线程1可能一直运行而无法退出

如上所示，由于缺乏可见性，即使线程2已将 flag 设置为 true，线程1所在的死循环依然不会终止。

场景 B：添加 volatile

将变量声明改为 private static volatile boolean flag = false;，结果如下：

图2：添加 volatile 后，变量变更立即生效，程序正常结束

1.2 防止指令重排序

为了提高性能，JVM 和编译器可能会对字节码层面的指令进行重新排列，这就是指令重排序。在单线程环境中，重排序不会影响程序的正确性；但在多线程并发环境下，若处理不当，就会引发严重的线程安全问题。

volatile 关键字的一个关键作用是禁止指令重排序，通过插入特定的内存屏障（Memory Barrier）来确保特定操作的有序性。

2. 单例模式中指令重排序的风险

回到双检锁单例模式的本质。很多开发者认为 instance = new Singleton(); 是一步完成的对象分配动作，但实际上它在 JVM 层面会拆分为三个步骤：

memoryAlloc：分配对象所需的内存空间。
initializeObject：在分配的内存上初始化对象（调用构造函数等）。
assignReference：将内存地址赋值给 instance 引用变量。

如果没有 volatile，JVM 可能会执行如下重排序：

原本预期的顺序是：1 → 2 → 3（先初始化，再挂接引用）。但可能发生的变化顺序是：1 → 3 → 2（先分配内存，再把地址赋给引用，最后才去初始化对象）。

这会引发什么样的并发灾难？

假设此时有两个线程 T1 和 T2 同时进入 getInstance()：

T1 发现 instance 为 null，进入同步块。
T1 开始执行 new Singleton()，它跳过了步骤2，直接执行了步骤3，此时 instance 引用不再为 null，指向了一块已分配但未初始化的内存。
就在这时，T1 发生了上下文切换（时间片耗尽或被挂起），此时 T1 尚未执行步骤2（对象构造函数未完成）。
此时 T2 醒来，发现 instance != null，于是认为对象已经构建完成，直接返回这个 instance。
T2 拿到的实际上是一个半成品/未初始化的对象，随后在调用该对象的方法时，必然会导致 NullPointerException 或其他不可预知的错误。