volatile 深入：可见性、有序性与 happens-before

凌晨 1 点，你被电话叫醒：配置中心推了一个紧急开关 degradeSearch = true，要把搜索降级掉。服务端日志显示「已收到新配置」，但业务线程还在跑旧逻辑，重启才生效——半小时后重启，又坏了一次。

排查到最后：那个 boolean 字段没加 volatile。管理线程写它，业务线程在 while 循环里读它——JIT 把读取的值缓存在了寄存器里，业务线程永远看到旧值。加上 volatile，问题消失。这个事故花了一个团队两小时，本质只值一个关键字。

然后面试官会顺着这个场景问你：

"不能。"——如果你只回答这两个字，面试就到此为止了。

面试官真正想听的是：volatile 保证可见性和有序性，但不保证原子性。紧接着，他会追问：

• 可见性是怎么实现的？缓存失效？内存屏障？
• 有序性是什么意思？指令重排为什么危险？
• 为什么 i++ 用 volatile 不行？
• DCL 单例为什么一定要加 volatile？
• volatile 写和读之间到底建立了什么关系？

这篇文章把 volatile 拆成 16 站，从可见性到内存屏障，从 happens-before 到 DCL 单例，一站一站把 volatile 讲透。

发车之前，先问自己：

• volatile 写操作后，CPU 缓存做了什么？
• StoreStore 屏障和 StoreLoad 屏障分别插在哪里？
• 对象创建的 3 条指令为什么可能被重排？
• happens-before 是「先发生」的意思吗？

带着这些问题，我们开始。

在钻进 volatile 的细节之前，先把多线程问题的「三性」和它们的责任人列清楚——volatile 只负责其中两性的半壁江山：

注意 volatile 的「责任边界」：可见性 ✓、有序性 ✓、原子性 ✗。后文 16 站基本都在回答三个问题——可见性怎么实现的（第 3、4 站）、有序性怎么实现的（第 5、6、8 站）、为什么原子性它管不了（第 7 站），外加它的「法律条文」happens-before（第 9 站）和生产落地（第 11、12 站）。

现代 CPU 都有多级缓存（L1、L2、L3），每个核心有自己独立的 L1/L2 缓存。Java 线程运行在不同的 CPU 核心上时，对同一个变量的读写可能发生在各自的缓存里——线程 A 修改了变量，值还在 L1 缓存中，线程 B 根本看不到。

volatile 保证可见性的机制可以概括为两条规则：

volatile write（写操作）：
  // 1. 将新值立即刷新到主内存
  // 2. 通过 MESI 协议通知其他 CPU 核心：这个缓存行无效

volatile read（读操作）：
  // 1. 使当前 CPU 缓存中该变量的缓存行失效
  // 2. 从主内存重新读取最新值

底层实现依赖 CPU 的 缓存一致性协议（如 MESI）和 Lock 前缀指令。JVM 会在 volatile 操作时插入特定的 CPU 指令（如 lock 前缀），强制把缓存行刷回主内存。

补一个 JMM（Java 内存模型）视角的对应：Java 规范里把「主内存」抽象为所有线程共享的变量之家，每个线程还有一份工作内存（Working Memory）——线程读变量 = 把工作内存的副本拉本地，写变量 = 改本地副本。volatile 的效果就是让写操作「立即提交回主内存」，读操作「强制从主内存重新拉取」。CPU 缓存层次是硬件实现，JMM 是语言层面的抽象——同一件事的两个刻度。

第 3 站说 volatile 写会「通知其他核心缓存失效」，这个通知靠的是 CPU 的缓存一致性协议。x86 用的是 MESI 协议，每个缓存行（Cache Line，通常 64 字节）有四种状态：

核心规则就一条：同一时刻，一个缓存行只能有一个核处于 M 或 E 状态。线程 A 写 flag 时，它所在核必须先把该缓存行置为 M，并通过总线发一个「无效化广播」——其他核收到后把各自缓存行的 flag 标记为 I。这就是「缓存失效」的硬件过程，不神秘，就是一次总线上的广播。

那 lock 前缀指令做了什么？在 x86 上，lock 前缀（如 lock add）有两个效果：

• 锁定缓存行：在操作完成前，其他核不能修改这一行——保证操作的独占性；
• 强制一致性：操作完成后，缓存行的新值刷回内存并广播失效——把 M 状态的「私有修改」立刻公开。

所以「volatile 写 = 带 lock 前缀的写指令」在 x86 上几乎是逐字成立的。而 x86 是强内存模型（Store-Store / Load-Load / Load-Store 都不重排），这让 JVM 在 x86 上可以少插屏障——第 8 站展开。面试被问「volatile 底层是什么」，标准答题链：volatile 写 → lock 前缀指令 → 缓存行锁定 + 刷回 + MESI 广播失效 → 其他核读到新值。

为了提高性能，编译器和 CPU 会对指令进行重排序。只要最终结果在单线程中不变，重排就是合法的。但在多线程环境下，重排可能导致灾难。

来看一个经典例子：

int a = 0, b = 0;
int x = 0, y = 0;

// 线程 1
a = 1;      // ①
x = b;      // ②

// 线程 2
b = 1;      // ③
y = a;      // ④

按程序顺序的「直觉」，可能的结果有 (x=1, y=0)、(x=0, y=1)、(x=1, y=1) 三种——唯独 x=0 且 y=0 不该出现：它意味着线程 1 在 a=1 之前读了 b（②在①前），线程 2 也在 b=1 之前读了 a（④在③前），两边同时把「先写后读」颠倒过来。

但 x=0, y=0 真的会发生——因为 ① 和 ② 之间没有数据依赖（a=1 的结果不参与 x=b 的计算），编译器/CPU 认为交换顺序不影响单线程结果，就放心重排了。单线程里 ①② 和 ②① 结果一样；多线程里，两边同时重排就撞出了第三种「不可能」。

volatile 通过建立 happens-before 关系来阻止特定的重排：

具体来说：

• volatile write 之前的普通写不会被重排到 volatile write 之后——保证其他线程看到 volatile flag 时，也能看到 flag 之前的所有写入。
• volatile read 之后的普通读不会被重排到 volatile read 之前——保证读 volatile flag 之后，能读到 flag 之前的所有写入。

第 5 站说「编译器和 CPU 会重排」，其实重排发生在三个层面，各自的「裁判」不同：

那为什么单线程程序从来没出过重排事故？因为 as-if-serial（串行语义）原则：JVM 允许任意重排，但重排后的执行结果必须和按程序顺序执行的结果一致——对单线程代码而言，观察者只能看到最终结果，而最终结果没变，重排就「不可见」。a=1; x=b; 单线程跑，不管怎么调顺序，你打印的结果都一样。

问题只出在多线程：另一个线程是「外部观察者」，它能窥见你的中间状态。重排把「中间状态」改变了，事故就来了。所以有序性的准确定义不是「指令不能动」，而是——不能把「别的线程能看到」的变化顺序搞乱。volatile 的屏障正是卡在「对别的线程可见」的边界上：volatile 写之前的写入，必须赶在 volatile 写「可见」之前完成。

面试官最爱问的问题之一。先看代码：

public class VolatileAtomicTest {
    static volatile int count = 0;

    public static void main(String[] args) throws Exception {
        CountDownLatch latch = new CountDownLatch(100);
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    count++; // 看似简单的自增
                }
                latch.countDown();
            }).start();
        }
        latch.await();
        System.out.println("count = " + count);
        // 期望：100000，实际：往往 < 100000
    }
}

问题出在 count++ 这个操作。它不是原子的——实际上它由 3 条指令组成：

// 第 1 步：read —— 从内存读取 count 的值
int temp = count;       // 比如读到 42

// 第 2 步：modify —— 在寄存器中加 1
temp = temp + 1;          // 变成 43

// 第 3 步：write —— 把新值写回内存
count = temp;            // 写入 43

volatile 只保证第 1 步读到的是最新值，但第 1 步和第 3 步之间，其他线程完全可以插入进来修改 count：

两个线程各做了一次 count++，count 应该变成 44，结果却只变成了 43——丢失了一次更新。100 个线程各做 1000 次，丢失的更新越多，最终结果离 100000 就越远。

volatile 的可见性和有序性最终都要落到 CPU 指令层面。JVM 通过在 volatile 操作前后插入内存屏障（Memory Barrier）来实现这两大保证。

在 x86 架构上，CPU 本身不会对 Store-Store、Load-Load、Load-Store 进行重排，唯一会重排的是 Store-Load。所以 JVM 在 x86 上做了优化：volatile write 之后只需要插入一个 lock 前缀指令（等效于 StoreLoad 屏障），其他屏障实际上是空操作（no-op）。

第 5 站给了直觉，这一站给规范原文。JSR-133 关于 volatile 的规则只有一句话：

这句话单独看平平无奇，但它是「安全发布」的法律基础。看一个真实模式——数据 + 标志位：

private byte[] buffer;                    // 普通字段
private volatile boolean ready = false;   // volatile 标志

// 初始化线程
buffer = new byte[1024];
... 填充 buffer 的所有数据 ...
ready = true;   // volatile write

// 业务线程
if (ready) {              // volatile read
    use(buffer);          // 一定看得到初始化线程写好的 buffer！
}

推导链（用 hb 的传递性）：

• 程序顺序规则：「填充 buffer」hb 「ready = true」（同线程内，前面的操作 hb 后面的）
• volatile 规则：「ready = true」（写）hb 「if (ready) 读到 true」（读）
• 传递性：「填充 buffer」hb 「use(buffer) 前」→ 业务线程读 buffer 时，所有数据必然已就位

反过来，标志位不加 volatile 就断了第一座桥：业务线程可能永远读不到 true（可见性），或者读到 true 时 buffer 还是半初始化的（有序性）——第 1 站的事故就是前者。

这是 Java 面试中最经典的问题之一。先看 Double-Checked Locking（DCL）的代码：

public class Singleton {
    private static volatile Singleton instance; // 必须 volatile！

    public static Singleton getInstance() {
        if (instance == null) {                 // 第一次检查（无锁，快速路径）
            synchronized (Singleton.class) {
                if (instance == null) {           // 第二次检查（有锁，防止重复创建）
                    instance = new Singleton();    // ⚠️ 问题出在这里
                }
            }
        }
        return instance;
    }
}

问题出在 instance = new Singleton() 这一行。它不是原子操作——字节码层面它包含 3 步：

new        // ① 分配内存空间
dup
invokespecial // ② 调用构造方法初始化对象
putstatic   // ③ 把引用赋值给 instance 变量

在正常顺序下，执行顺序是 ① → ② → ③。但编译器和 CPU 可能将 ② 和 ③ 重排为 ① → ③ → ②（② ③ 之间没有数据依赖）：

重排之后的灾难场景：

// 线程 A 执行 getInstance()
T1: 分配内存
T2: instance = 引用          // 引用不为 null 了！但对象还没初始化

// 线程 B 执行 getInstance()
T3: if (instance == null)   // false！跳过 synchronized 块
T4: return instance          // 返回了一个半初始化的对象 → NPE 或逻辑错误

// 线程 A 继续
T5: 初始化对象               // 但线程 B 已经拿到了未初始化的引用

volatile 如何解决这个问题？ 加入 volatile 后，putstatic（volatile write）之前会插入 StoreStore 屏障，阻止 ② 和 ③ 重排。保证其他线程看到 instance != null 时，对象一定已经初始化完毕——正好就是第 9 站「数据 + 标志位」模式的一个特例：instance 本身就是那个「标志 + 数据」合一的引用。

这两个词在面试里总被放在一起问。别急着答「一个轻量一个重量」，先摆事实：

注意一个反直觉的点：synchronized 其实也保证可见性和有序性——很多人只把它和「互斥」挂钩。它靠的是：进锁的读和出锁的写都有屏障语义，加上同一时刻只有一个线程持锁，「串行化」天然带来可见性。所以「用 synchronized 就一定能看到最新值」是成立的；「看到最新值就需要 synchronized」才是错的——volatile 就够，还更便宜。

回到第 1 站的事故，把它泛化成一个排查模式：「A 线程写了，B 线程看不到，重启就好」= 可见性问题，99% 是共享字段少了 volatile（或没用线程安全容器）。

生产里 volatile 的三块主力阵地：

private volatile boolean running = true;
private volatile boolean degradeSearch = false;  // 第 1 站事故里的开关

// 工作线程：while 循环里反复读
while (running) {
    if (degradeSearch) { // 配置推送后立即生效，不用重启
        return degradeResult();
    }
    doWork();
}

// 管理线程（配置中心回调 / 停机钩子）
degradeSearch = true;   // volatile write，工作线程下一轮循环必看到
running = false;        // 优雅停机开关同理

private volatile Config config;   // 整个对象一次发布，不逐字段改

// 更新线程：构造好新对象，一次性替换引用
Config next = Config.loadFromRemote();
config = next;   // volatile write：读到新引用的线程，必能看到 next 构造完成的所有字段

// 读线程：永远读到「完整」的对象，不会看到半更新状态
Config c = this.config;   // 局部缓存一次，避免两次读之间被换掉
if (c != null) c.getPort();

阵地三就是 DCL 单例（第 10 站）。三条最佳实践，直接当 Code Review 清单用：

• volatile 只用于「状态」，不用于「数据累积」：count++、list.add() 这类复合操作看到 volatile 就该打回——换成 AtomicXxx / 并发容器 / 锁。
• 「数据 + 标志」成对出现时，标志必须 volatile：先填数据后翻标志，缺一不可（第 9 站的推导链）。
• 读对象引用先存局部变量：Config c = this.config——两次读 this.config 之间引用可能已被换掉，用局部变量固定住「这一轮看到的版本」。

第 12 站讲了「怎么用」，这一站给一张「用不用」的速查表。知道什么时候用 volatile 是基本功，知道什么时候不用 volatile 才是功力。

适合用 volatile 的场景：

volatile boolean running = true;

// 工作线程
while (running) {
    // 干活...
}

// 管理线程
running = false; // 工作线程下次循环时一定能看到 false

volatile Config config;

// 初始化线程
Config c = new Config(loadFromFile()); // 构造完成
config = c;  // volatile write：保证其他线程看到 config != null 时，Config 内部字段也已初始化

// 其他线程
if (config != null) {
    config.getPort(); // 一定能读到正确的值
}

// 见第 10 站，volatile 防止指令重排导致半初始化对象

不适合用 volatile 的场景：

volatile vs AtomicXxx：

// volatile：只保证可见性和有序性，适合简单的读写
volatile int flag = 0;
flag = 1;              // ✅ 单次写，安全
int x = flag;          // ✅ 单次读，安全
flag++;                // ❌ 读-改-写，不安全

// AtomicInteger：基于 CAS，保证原子性 + 可见性
AtomicInteger count = new AtomicInteger(0);
count.incrementAndGet(); // ✅ CAS 循环，原子操作
count.compareAndSet(0, 1); // ✅ CAS，原子操作

第 9 站的「数据 + 标志位」有一个更隐蔽的推论：把引用声明成 volatile，发布时连对象内部字段一起「打包可见」。为什么？

回忆第 10 站：对象创建的 ② 初始化 和 ③ 引用赋值 可以被重排。JMM 为了防止这种重排「泄漏」给别的线程，规定：volatile 写一个引用时，该引用指向的对象的完整构造（包括它所有的 final 字段和普通字段的初始化）都 happens-before 这个 volatile 写。于是：

• 「对象构造完成」hb 「config = c」（volatile 写）
• 「config = c」hb 「另一个线程的 config 读」
• 传递：「对象构造完成」hb 「另一个线程使用 config」→ 看到的对象保证构造完毕

这就是「安全发布（Safe Publication）」：发布一个对象的所有合法途径只有四种——① 用 final 字段（构造完成即天然安全）② 用 volatile 引用发布 ③ 用锁保护 ④ 用线程封闭（不共享）。其他任何方式（普通字段直接赋值后给出去）都可能出现「引用可见、内部字段还是半初始化」的幽灵。

顺带把 final 的语义也串上：final 字段在构造方法执行完时就「定格」——任何线程读到持有该 final 字段的对象（哪怕引用本身是普通字段泄露出去的），final 字段指向的对象也是构造完毕的。final 管「构造期」，volatile 管「发布期」，两者合起来覆盖了对象可见性的全部场景。完整的 final 域规则（包括 final 域逃逸的坑）见「JMM 与 happens-before」篇。

volatile 讲到这里，面试里剩下的基本都是固定追问。四道高频题，标准答案各一段：

用一张表把 volatile 的所有特性收拢起来：

volatile 相关的 happens-before 规则：

"volatile 保证可见性和有序性，不保证原子性。

 可见性：volatile write 会立即刷回主内存，并让其他核心的缓存行失效（lock 前缀 + MESI 广播）；
         volatile read 会使本地缓存失效，从主内存重新加载。

 有序性：通过在操作前后插入内存屏障，阻止编译器和 CPU 对屏障两侧的指令重排。
         例如 DCL 单例中，volatile 阻止了对象创建时 '赋值引用' 和 '初始化' 的重排。

 不保证原子性：count++ 是读-改-写三步操作，volatile 只保证读到的值是最新的，
              但三步之间可能被其他线程干扰，导致更新丢失。应该用 AtomicInteger。

 生产用法：状态标志、一次性安全发布、DCL 单例；volatile 引用能『安全发布』整个对象——
 它和 final 一起构成对象可见性的两条腿。"