JMM是Java虚拟机定义的多线程内存访问规范，通过抽象主内存与工作内存、happens-before规则及volatile/synchronized等关键字语义，桥接硬件内存屏障（如lfence/sfence），保障可见性、有序性，但不保证原子性。
Java 内存模型（JMM）本身不直接暴露硬件级的 Read Barrier 和 Write Barrier，但它通过抽象语义将这些底层机制“翻译”成程序员可感知的行为——比如 volatile、final、synchronized 的语义。真正起物理作用的，是 JVM 在生成机器码时，根据平台特性插入对应的硬件内存屏障指令（如 x86 上的 lfence/sfence），从而让 CPU 执行符合 JMM 要求的内存操作顺序和可见性保证。
Read Barrier 的物理功效：强制重载最新值
硬件层面的 Read Barrier（如 x86 的 lfence）本质是阻断后续读指令对缓存/预取数据的依赖，要求 CPU 在屏障之后的所有 load 操作必须：
- 清空或绕过当前处理器的加载缓冲区（Load Buffer）和乱序执行队列中的待决读请求；
- 从更权威的内存层级（如 L1/L2 缓存一致性协议保证的最新副本，或直接回写到主内存后的值）重新加载数据；
- 确保能看到之前所有处理器执行过的、已通过 Store Barrier 刷出的写结果。
在 Java 中，这对应于 volatile 读或进入 synchronized 块时的隐式 Load Barrier。例如：if (flag) 若 flag 是 volatile，JVM 就会在该读操作前插入 Read Barrier，防止线程用自己 cache 里过期的 false 值跳过逻辑。
Write Barrier 的物理功效：强制刷出写数据
硬件 Write Barrier（如 x86 的 sfence）核心是阻止写指令越过屏障提前提交，它让 CPU 必须：
立即学习“Java免费学习笔记（深入）”；
- 等待屏障前所有 store 指令完成写缓冲区（Store Buffer）的排队，并将数据真正推送到缓存一致性总线（如 MESI 协议下的共享状态更新）；
- 确保这些写对其他 CPU 核心可见（即触发缓存行失效、广播等硬件动作）；
- 禁止编译器和 CPU 把屏障后的写操作重排到屏障前。
Java 中，volatile 写、final 字段初始化结束、或退出 synchronized 块时，JVM 都会插入 Store Barrier。例如：data = 42; flag = true; 若 flag 是 volatile，JVM 保证 data 的写入一定先于 flag 的写入对其他线程可见——靠的就是在 flag = true 后插 Store Barrier，把 data 和 flag 一起刷出去。
JMM 如何桥接硬件与语义
JMM 不规定具体指令，而是定义一套“ happens-before”规则。JVM 实现者依据这些规则，在不同 CPU 架构上选择最轻量且等价的硬件屏障：
- x86/x64 因其强内存模型，默认 store 有序、load-store 有序，所以
volatile写只需sfence（实际常被lock addl $0,0(%rsp)替代），读只需lfence或无显式指令； - ARM/AArch64 弱内存模型，则必须为每个
volatile读/写都插入dmb ish（全屏障）才能满足 JMM 要求； - 所谓 “Read Barrier 对应 LoadLoad + LoadStore”，“Write Barrier 对应 StoreStore + LoadStore”，其实是 JVM 把 JMM 的原子性与可见性需求，映射为硬件能理解的指令组合。
不是所有读写都需要屏障
普通变量读写没有屏障插入——这是性能关键。JMM 允许编译器优化、CPU 乱序执行，只要不破坏单线程语义。只有当存在跨线程的“通信意图”（如用 volatile 传递状态、用 synchronized 保护临界区），JVM 才按需注入屏障。换句话说：屏障是 JMM 对硬件发出的“同步请求”，不是常态，而是契约履行点。
