内存屏障是JVM依volatile等语义自动插入的硬件级指令，非Java语法；volatile写插入StoreStore+StoreLoad屏障，读插入LoadLoad+LoadStore屏障，协同CPU硬件（如MESI、store buffer）保障有序性与可见性。
内存屏障不是 Java 语言层面的语法或 API，而是 JVM 在生成机器码时，根据 volatile、synchronized 等语义，自动插入的硬件级顺序约束指令。它不拦截执行，而是向 CPU 发出“顺序承诺”，靠底层硬件组件协同响应来兑现。
Load 屏障：不只是读新值，而是控制读与读、读与写的先后
Load 屏障（如 LoadLoad、LoadStore）本质是让 CPU 等待前面的读操作真正拿到有效数据后，才允许后续访存指令推进。
- LoadLoad 屏障：确保屏障前所有 load 指令的数据已从 cache 或内存返回寄存器，之后的 load 才能开始地址翻译和取数。例如 volatile 读后紧接着读普通变量，防止后者被重排到前者之前。
- LoadStore 屏障：强制屏障前的 load 完成（含 TLB 查找和数据到达），才允许屏障后的 store 进入 store buffer。常见于“检查标志再写数据”场景，避免写基于过期判断执行。
- x86 上 LoadLoad 常编译为 lfence，会清空重排序缓冲区中待执行的 load；ARMv8 对应 dmb ishld，作用于 inner shareable domain，等待 cache line 状态稳定（如 I→S 过渡完成）。
Store 屏障：不只是刷缓存，而是保障写可见性与顺序语义
Store 屏障（如 StoreStore、StoreLoad）核心是管理 store buffer 行为，并触发缓存一致性协议动作，确保写操作对其他核真正“可见”。
- StoreStore 屏障：要求屏障前的 store 必须提交到 L1d cache（至少完成 tag 更新和数据写入），后续 store 才能入 buffer。x86 天然 FIFO 保证，JVM 通常省略显式 sfence；ARMv8 则必须用 dmb ishst 强制刷 buffer 并阻塞后续写入。
- StoreLoad 屏障：最强屏障，需同时完成两件事——把 store buffer 中靠前的写刷新到 cache（并触发 MESI 的 invalidate 消息），同时让其他核的 invalidation queue 处理完对应失效请求，才允许后续 load 执行。volatile 写后立即跟读，就靠它兜底保证新值能被拉进来。
- 它不是简单“等写完”，而是协调 store buffer、invalidation queue、cache coherency protocol（如 MESI）三者状态达成全局一致。
硬件协作的关键组件
内存屏障的效果不是单条指令决定的，而是依赖以下硬件机制共同响应：
立即学习“Java免费学习笔记（深入）”；
- Store buffer：暂存未提交的写，屏障会控制其写入顺序与刷出时机；
- Invalidation queue：接收其他核发来的失效请求，屏障会等待关键失效完成；
- MESI 协议状态机：屏障促使 cache line 在 Modified/Shared/Invalid 状态间正确迁移；
- 指令发射调度器：在 barrier 处暂停特定类型指令（load/store）的乱序发射。
为什么 volatile 写要配 StoreStore + StoreLoad？
单独 StoreStore 不能保证后续读看到新值，单独 StoreLoad 也无法防止前面普通写被重排到 volatile 写之后。两者组合才能完整兑现 JMM 的 happens-before 承诺：
- StoreStore → 确保 “a = 1; b = true;” 中 a 的写不会被拖到 b 之后；
- StoreLoad → 确保 “b = true;” 后的 “if (b) return a;” 能读到 a=1，而非旧值 0。
- 这个组合在 x86 上常由一条 lock xchg 隐含实现，在 ARM 上则需两条独立 dmb 指令。
