内存屏障是CPU和编译器共有的秩序约束，本质是同步指令，确保前后读写顺序与可见性，但不保证原子性；Java中volatile自动插入StoreStore、StoreLoad、LoadLoad和LoadStore四类屏障以满足JMM规范。
内存屏障不是Java专属，而是CPU和编译器共有的“秩序约束”
内存屏障本质是一条同步指令，告诉CPU或编译器：“前面的读写必须完成并落地，才能执行后面的读写”。它不解决数据竞争本身，但为正确同步提供底层支撑。你在Java里写 volatile、在C++里用 std::atomic_thread_fence、甚至在Linux内核里写 smp_mb()，背后都在插入某种形式的内存屏障。
容易踩的坑是把它当成“万能锁”——屏障只管顺序和可见性，不管原子性。比如对一个 int 做两次 volatile 写，中间插个屏障，也不能保证这两步合起来是原子的。
LoadLoad / LoadStore / StoreStore / StoreLoad 四种组合怎么选
这四种不是并列选项，而是按“前后操作类型”自动匹配的约束模式。关键看你要保护哪两步之间的依赖关系：
-
LoadLoad：读A之后要读B，且B依赖A的结果（比如先读flag，再读data）→ 插在两个读之间，防止后读被提前 -
LoadStore：读A之后要写B，且B的值依赖A（比如读配置后更新缓存）→ 防止写被重排到读之前 -
StoreStore：写A之后写B，且B依赖A的状态（比如先写日志头，再写日志体）→ 确保A刷入内存后再执行B -
StoreLoad：写A之后读B，且B依赖A的完成（最重，volatile写后必插）→ 强制A刷新到主内存，再读B，避免读到旧缓存
Java里 volatile 怎么悄悄插入这四道屏障
你没手动写任何屏障，但JVM替你加了。规则很固定：
- 每次
volatile写前：插入StoreStore（确保之前所有普通写已落地） - 每次
volatile写后：插入StoreLoad（强制刷出+阻塞后续读） - 每次
volatile读后：插入LoadLoad和LoadStore（保证后续读/写不越过本次读）
注意：StoreLoad 是唯一会显著影响性能的屏障，在x86上它对应 lock addl $0,0(%rsp) 这类全屏障指令，会清空store buffer并同步所有核心缓存行。
别以为x86安全就忽略屏障逻辑
x86硬件天然禁止大多数重排序（比如不会把Store重排到Load前），所以 StoreLoad 在x86上实际开销比ARM/RISC-V小得多。但这不等于你可以删掉 volatile 或绕过屏障语义——JMM规范要求跨平台行为一致，而JIT编译器在不同CPU上会生成适配的屏障指令。你在x86上靠硬件兜底，换到ARM上可能立刻暴露竞态。
真正容易被忽略的是：屏障只作用于它所在线程的指令流，不自动传播到其他线程。也就是说，线程A写了带 StoreLoad 的 volatile 变量，线程B要看到效果，必须自己也执行一次 volatile 读（触发它的 LoadLoad + LoadStore），否则仍可能读到本地缓存旧值。
