【JVM原理详解】43-volatile的内存语义与实现原理

43-volatile的内存语义与实现原理

引言

前两篇我们建立了JMM的抽象模型，并拆解了原子性、可见性、有序性三大特性。其中volatile反复出现——它是JMM中最轻量、最常用、也最容易被误解的同步原语。volatile只修饰字段，却同时影响可见性和有序性，底层通过CPU的Lock前缀指令和MESI缓存一致性协议落地。

本篇聚焦volatile本身：它有哪两大内存语义？JVM如何用内存屏障实现有序性？Lock前缀指令和MESI/总线锁如何落地可见性？为什么volatile不能保证i++的原子性？最后用DCL单例串联所有知识点。读完本篇，volatile对你应该不再有"黑盒"。

volatile的两大语义

JMM赋予volatile两大语义：可见性与有序性。注意，没有原子性——这是volatile最容易踩的坑。

语义一：可见性

volatile保证：一个线程对volatile变量的写，对其他线程的读立即可见。具体表现为：

• 写：volatile变量的写会立即刷新到主内存（store+write），并使其他CPU缓存中该变量的副本失效
• 读：volatile变量的读会强制从主内存重新加载（read+load），不使用工作内存的旧副本

这与普通变量"何时同步不确定"形成鲜明对比。上一篇的VisibilityDemo里，普通boolean running可能让worker线程永远循环；加volatile后，主线程的修改必然被worker看到。

需要澄清一个常见误解：volatile的"立即"不是零延迟。它意味着在JMM规则下，写后任何后续读都能看到新值，但物理上仍有缓存一致性协议的传播延迟（纳秒级）。JMM是规范保证，不是物理瞬时。

语义二：有序性

volatile通过禁止特定类型的指令重排序保证有序性。这是volatile在JDK 5（JSR-133）后语义重构的核心——旧版Java的volatile只保证可见性，不保证有序性，导致DCL等模式不安全。

JMM为volatile设定的重排序规则表如下（"N"表示禁止重排序）：

核心规则可以提炼为：

• volatile写之前的所有普通读写，不能重排到volatile写之后（保证写前操作对后续读volatile的线程可见）
• volatile读之后的所有普通读写，不能重排到volatile读之前（保证读到volatile新值后再执行后续依赖操作）
• volatile写和volatile读之间不能重排

这套规则用内存屏障落地，下一节详述。

内存屏障的实现

volatile的有序性通过在读写前后插入内存屏障实现。JVM在生成字节码到机器码时，按以下规则插入屏障：

volatile写的屏障策略

[普通写/读操作] StoreStore ← 屏障1：保证前面的普通写先于volatile写完成 [volatile 写] StoreLoad ← 屏障2：保证volatile写对后续读可见，且后续读不重排到写前 [后续操作]

• 写前StoreStore：禁止前面的普通写重排到volatile写之后。例如DCL里"初始化对象字段"（普通写）必须在"把对象引用赋给instance"（volatile写）之前完成
• 写后StoreLoad：保证volatile写的结果对所有处理器可见后，才执行后续读。StoreLoad是全能屏障，开销最大，这是volatile写比普通写慢的主因

volatile读的屏障策略

[volatile 读] LoadLoad ← 屏障3：禁止后面的普通读重排到volatile读之前 LoadStore ← 屏障4：禁止后面的普通写重排到volatile读之前 [后续普通读/写]

• 读后LoadLoad：保证volatile读之后的普通读不重排到volatile读之前。确保你先看到volatile新值，再读依赖它的普通变量
• 读后LoadStore：保证volatile读之后的普通写不重排到volatile读之前

注意volatile读之前不需要屏障——读操作本身不会"污染"前面的操作，前面是普通读还是volatile读对当前volatile读没有顺序约束需求。

屏障插入的完整图示

线程A写 volatile v: ┌──────────────────┐ │ write normal x │ ← 普通写 │ StoreStore ───── │ ← 屏障：x 必须先于 v 完成 │ write volatile v │ ← volatile写 │ StoreLoad ───── │ ← 屏障：v 必须完全可见后才允许后续读 │ read anything │ └──────────────────┘ 线程B读 volatile v: ┌──────────────────┐ │ read volatile v │ ← volatile读 │ LoadLoad ───── │ ← 屏障：后续普通读不能上提 │ LoadStore ───── │ ← 屏障：后续普通写不能上提 │ read normal y │ ← 依赖v的普通读 │ write normal z │ └──────────────────┘

不同CPU架构的屏障差异

内存屏障是CPU架构相关的概念，不同架构的内存模型强弱不同：

• x86（TSO模型）：本身是强有序，LoadLoad和LoadStore基本天然成立，只有StoreLoad需要实际屏障（mfence或lock前缀）。所以x86上volatile读几乎无额外开销，volatile写主要贵在StoreLoad
• ARM/POWER（弱内存模型）：四种屏障都需要实际插入，volatile的开销在ARM上比x86显著更大
• JVM的职责：在弱内存模型CPU上补齐屏障，在强内存模型CPU上不冗余插入。HotSpot针对每种CPU生成不同的屏障指令序列

volatile的底层实现

内存屏障是JVM层面的抽象，最终要落到CPU指令。volatile在HotSpot中的底层实现，核心是Lock前缀指令，再往下是MESI缓存一致性协议和总线锁。

Lock前缀指令

x86上，HotSpot为volatile写生成带有Lock前缀的指令，通常是lock addl $0, 0(%rsp)（向栈顶加0，本身无副作用，但Lock前缀触发缓存一致性机制）。Lock前缀指令的作用：

1. 锁定缓存行：对该指令涉及的内存区域，通过MESI协议锁定缓存行
2. 刷写缓冲：把写缓冲（Store Buffer）中的内容刷入缓存，并传播失效消息
3. 全局可见：保证该写操作对所有处理器可见后，才继续执行后续指令
4. 禁止重排：作为内存屏障，禁止前后指令的重排序

Lock前缀指令等价于一个全功能内存屏障（同时具备LoadLoad/StoreStore/LoadStore/StoreLoad效果），这与JMM对volatile写后StoreLoad的需求吻合。选择lock addl而非mfence，是HotSpot的历史优化——早期mfence在某些CPU微架构上比lock addl慢，HotSpot优先用后者。

MESI缓存一致性协议

Lock前缀指令的"锁定缓存行"依赖MESI协议。上一篇提过MESI的四种状态（M/E/S/I），volatile写的完整流程是：

线程A写 volatile v = 1: 1. CPU-A 发现 v 所在缓存行状态为 S (Shared) 2. CPU-A 通过总线发送 "Invalidate" 消息，要求其他CPU弃用该缓存行 3. 其他CPU收到消息，把对应缓存行置为 I (Invalid)，回 ACK 4. CPU-A 收到所有 ACK 后，缓存行升级为 M (Modified) 5. CPU-A 写入新值 1 到自己的 L1 6. (后续) 当 CPU-A 淘汰该缓存行时，写回主内存 线程B读 volatile v: 1. CPU-B 发现 v 所在缓存行状态为 I (Invalid) 2. CPU-B 发送 "Read" 消息，从主内存或 CPU-A 的 L1 拿到最新值 3. CPU-B 缓存行变为 S (Shared)，读到新值 1

关键点：volatile写的"立即可见"靠的是MESI主动失效其他缓存，而非被动等待同步。这就是为什么volatile写比普通写贵——它要触发跨CPU的总线消息往返。

总线锁：极端情况

当变量跨缓存行（一个变量横跨两个缓存行，或操作无法用单个缓存行锁定）时，MESI无法锁定单个缓存行，CPU会退化为总线锁（Bus Lock）——锁住整个系统总线，期间其他CPU不能访问任何内存。总线锁的代价极高（数十到数百倍于普通访问），所以：

• JVM和CPU都尽量避免总线锁。HotSpot会对volatile字段做缓存行对齐优化
• @Contended注解（JDK 8+，需-XX:-RestrictContended）通过填充字节避免伪共享，间接减少总线锁风险
• 64位JVM上，long/double的volatile读写通常能保证单缓存行（64字节缓存行足够容纳一个8字节变量+对齐填充）

volatile读的底层

volatile读在x86上几乎"免费"——因为x86的强内存模型下，读操作天然不会重排到前面的写之前，LoadLoad和LoadStore屏障是空操作。HotSpot在x86上对volatile读通常不插入任何额外指令，只是阻止编译器把读重排到后续操作之前。

但在ARM等弱内存模型CPU上，volatile读后需要插入dmb ishld（数据内存屏障）等指令，开销不可忽略。这就是同样一段Java代码在x86和ARM上volatile性能差异较大的原因。

volatile不保证原子性

这是volatile最常被误解的点。volatile保证可见性和有序性，但不保证原子性。volatile int i; i++;依然不是线程安全的。

i++的分解

i++分解为：

1. read i (从主内存读，volatile保证读到最新值) 2. i + 1 (CPU寄存器内加1) 3. write i (写回，volatile保证立即刷出)

步骤1和3各自是volatile读写，可见性没问题。但1和3之间可能被其他线程插入——线程A读到i=0，线程B也读到i=0，各自加1写回1，丢失一次自增。volatile无法阻止这种"读-改-写"的交错，因为读和写是两个独立的volatile操作，中间没有原子性保护。

代码验证

// 适用 JDK 11/17publicclassVolatileAtomicityDemo{privatestaticvolatileintcounter=0;publicstaticvoidmain(String[]args)throwsInterruptedException{intthreads=100;intperThread=10_000;Thread[]ts=newThread[threads];for(inti=0;i<threads;i++){ts[i]=newThread(()->{for(intj=0;j<perThread;j++){counter++;// volatile不保证原子性}});ts[i].start();}for(Threadt:ts)t.join();System.out.println("Expected: "+(threads*perThread));System.out.println("Actual: "+counter);// 几乎必然小于预期}}

即使加了volatile，结果依然小于预期。修复方案：用AtomicInteger（CAS保证读-改-写原子）、synchronized（加锁包裹自增）、或LongAdder（高并发更优）。

volatile的适用场景

既然不保证原子性，volatile适合什么场景？当一个变量只被一个线程写、其他线程只读时，volatile是最合适的轻量同步。典型场景：

• 状态标志位：volatile boolean running，一个线程设置、另一个线程轮询
• 一次性初始化发布：DCL单例的volatile instance，发布对象引用
• 配置快照：一个管理线程周期性更新volatile配置值，工作线程周期性读取

如果涉及"读-改-写"复合操作，volatile不够用，必须升级到原子类或锁。

volatile vs synchronized对比

volatile和synchronized是Java并发的两大基础原语，各自定位不同。以下是系统对比：

选择原则：

• 只需可见性，且操作是"单写多读"——用volatile
• 需要原子性保护复合操作，或临界区有多个步骤——用synchronized或Lock
• 不确定时优先synchronized，它更不容易出错；确认无复合操作再降级为volatile

典型应用：DCL单例

**双重检查锁定（DCL）**是volatile最经典的应用场景，也是volatile"有序性"语义的最佳演示。

为什么需要volatile

上一篇讲过，DCL的问题在于instance = new Singleton()可能被重排序为"分配内存→赋值引用→初始化对象"，导致其他线程拿到半初始化对象。volatile禁止这种重排序，让"初始化对象"（普通写）必须在"赋值instance"（volatile写）之前完成。

完整DCL实现

// 适用 JDK 5+（volatile语义在JSR-133重构后安全）publicclassSingleton{// volatile 保证可见性 + 有序性privatestaticvolatileSingletoninstance;privatefinalintconfig;privateSingleton(){this.config=42;}publicstaticSingletongetInstance(){if(instance==null){// 第一次检查：无锁快速路径synchronized(Singleton.class){if(instance==null){// 第二次检查：防止重复创建instance=newSingleton();}}}returninstance;}}

volatile在DCL中的具体作用

假设线程A和线程B同时调用getInstance()：

1. 线程A进入synchronized块，执行instance = new Singleton()
2. 由于volatile的StoreStore屏障，构造函数内的this.config = 42（普通写）必须先于instance赋值（volatile写）完成
3. 线程A退出synchronized块（unlock隐含StoreLoad，保证instance写入全局可见）
4. 线程B在第一次检查时读到instance != null，直接返回。由于volatile读后LoadLoad屏障，线程B后续访问instance.config时，一定读到完整的42，而非默认值0

去掉volatile会怎样？线程B可能在第一次检查时读到非null的instance，但config还是0（构造函数未跑完）。这就是volatile在DCL中不可替代的作用——它保证"对象引用可见"与"对象内容可见"的有序性。

DCL的替代方案

虽然DCL+volatile是经典写法，但现代Java有更简洁的单例实现：

// 方案1：静态内部类（推荐，无需volatile）publicclassSingleton{privateSingleton(){}privatestaticclassHolder{staticfinalSingletonINSTANCE=newSingleton();}publicstaticSingletongetInstance(){returnHolder.INSTANCE;}}// 利用了类加载的线程安全性：Holder类的初始化由JVM保证原子+可见// 方案2：枚举（Effective Java推荐，防反射攻击）publicenumSingleton{INSTANCE;}

静态内部类方案利用类加载的线程安全性——JVM在初始化Holder类时，会通过类加载锁保证INSTANCE的创建原子且可见，效果等价于synchronized+volatile，且无显式同步代码。枚举方案则进一步防止反射破坏单例，是Effective Java的首选。

实践要点

1. volatile不是"轻量synchronized"。它只解决可见性和有序性，不解决复合操作原子性。把volatile当synchronized用是常见误用。

2. volatile写有StoreLoad开销。在极高频写的热点路径上，volatile写的StoreLoad屏障可能成为瓶颈。评估是否真的需要可见性，或能否用其他设计（如线程局部计算+周期性聚合）规避。

3. x86上volatile读几乎免费。强内存模型让LoadLoad/LoadStore屏障空操作，所以volatile读在x86上和普通读几乎一样快。但在ARM/POWER上要谨慎，读后屏障有实际开销。

4. 警惕long/double的非原子读写。虽然64位HotSpot保证long/double读写原子，但32位JVM或某些边缘场景仍可能有风险。用volatile修饰long/double可强制原子性（虽然主要用途仍是可见性）。

5. 避免volatile数组的误解。volatile int[] arr只保证arr引用的可见性，不保证数组元素的可见性。对arr[i]的读写没有volatile语义。需要元素级可见性用AtomicIntegerArray。

6. DCL优先用静态内部类替代。虽然volatile+DCL正确，但静态内部类更简洁、无显式同步、性能好，除非需要延迟加载控制，否则优先后者。

7. 用-XX:+PrintAssembly观察volatile实现。配合HSDIS插件可以看到volatile写生成的lock addl指令。这是验证volatile底层实现的最直接手段，适合深入学习时使用。

8. volatile不能替代final。final字段在构造函数完成后对其他线程可见，且JMM保证其值不变化。volatile字段值可变，每次读都要刷新。能用final就用final，需要可变可见性才用volatile。

小结

• volatile有两大语义：可见性（写刷新主内存+失效其他缓存，读强制重载）和有序性（内存屏障禁止重排），不保证原子性
• 内存屏障策略：volatile写前插StoreStore、写后插StoreLoad；volatile读后插LoadLoad和LoadStore。StoreLoad开销最大
• 底层实现：x86上volatile写用Lock前缀指令（如lock addl），触发MESI缓存失效；跨缓存行时退化为总线锁，代价极高
• MESI协议：volatile写通过发送Invalidate消息使其他CPU缓存副本失效，保证"立即可见"的JMM语义
• 不保证原子性：volatile i++依然不安全，因为读-改-写是两个独立volatile操作，中间可被插入。原子自增用AtomicInteger/LongAdder
• volatile vs synchronized：volatile轻量无锁但只解决可见性+有序性；synchronized重但保证原子性。单写多读用volatile，复合操作用synchronized
• DCL单例是volatile的经典应用：保证"对象引用赋值"与"对象内容初始化"的有序性，避免半初始化对象泄漏

更多内容：JVM调优实战