Java 内存模型（JMM）- 内存屏障

内存屏障（Memory Barrier）是一种 CPU 或 JVM 级别的指令，用于禁止特定类型的指令重排序 并强制内存可见性 。Java 内存模型（JMM）定义了四种抽象的屏障类型，它们组合使用来实现 volatile、synchronized 等的语义。

屏障类型	组合	禁止的重排序	典型用途
LoadLoad	`Load1; LoadLoad; Load2`	禁止 `Load1` 和 `Load2` 重排序，保证 `Load1` 先于 `Load2` 读取内存	`volatile` 读之后，禁止后续普通读重排到前面
StoreStore	`Store1; StoreStore; Store2`	禁止 `Store1` 和 `Store2` 重排序，保证 `Store1` 的数据先于 `Store2` 对其他处理器可见	`volatile` 写之前，保证之前的所有普通写已完成
LoadStore	`Load1; LoadStore; Store2`	禁止 `Load1` 和 `Store2` 重排序，保证读取操作先于写入操作	`volatile` 读之后，禁止后续写重排到前面
StoreLoad	`Store1; StoreLoad; Load2`	全能屏障：禁止 `Store1` 和 `Load2` 重排序，且强制将写缓冲刷到主存，并使其他缓存行失效	`volatile` 写之后（或 `synchronized` 释放锁时），保证之前的写对所有后续读可见

其中 StoreLoad 是最"重"的屏障，它兼具其他屏障的大部分效果，开销也最大。

StoreStore 屏障的作用：保证屏障之前的所有普通写操作，都先于屏障之后的写操作提交到内存（对其他处理器可见）。

根据 JMM 规范，对一个 volatile 变量写入时，会在写入前插入一个 StoreStore 屏障。

java 复制代码

// 普通写
x = 1;
// StoreStore 屏障（保证 x=1 先于下面的 volatile 写）
volatile int v = 2;  // volatile 写

如果没有这个屏障，CPU 可能先执行 v = 2，再执行 x = 1（重排序）。这会导致另一个线程看到 v 被更新了，但 x 还是旧值，破坏了正确性。

StoreLoad 屏障的作用：

对一个 volatile 变量写入后，会插入一个 StoreLoad 屏障。

java 复制代码

volatile int v = 2;  // volatile 写
// StoreLoad 屏障
int y = x;           // 普通读

StoreLoad 保证了 v = 2 对所有处理器立即可见，并且 y = x 不会重排到 v = 2 之前。

注意：在 x86 架构下，volatile 写实际上对应 lock addl 指令，该指令自带 StoreLoad 屏障效果，不额外插入单独的屏障指令。但在 JMM 抽象层面，仍然认为有一个 StoreLoad。

操作	插入的屏障	说明
读一个 volatile 变量	1. 读之后插入 LoadLoad 2. 读之后插入 LoadStore	保证后面对普通变量/普通写的访问不会重排到读之前
写一个 volatile 变量	1. 写之前插入 StoreStore 2. 写之后插入 StoreLoad	保证前面的普通写已完成，并让新值立即可见

图示：

复制代码

普通写        普通读/写
   ↓
[StoreStore]
   ↓
volatile 写
   ↓
[StoreLoad]   ← 最重，保证可见性和禁止重排序

volatile 读
   ↓
[LoadLoad]
[LoadStore]
   ↓
普通读/写

因此，在 x86 上，真正生效的只有 StoreLoad 屏障（通过 lock 前缀实现），其他屏障在硬件层面通常不需要做额外事情。但 JMM 为了跨平台统一，依然定义了这四种抽象屏障。