volatile读操作插入loadload+loadstore屏障，禁止后续读写重排到其前；写操作插入storestore+storeload屏障，确保前面所有普通写不重排到其后、其后的读不提前到之前。
Java 内存模型（JMM）本身不直接暴露“内存屏障”指令给程序员，而是通过 volatile、synchronized、final 字段初始化以及 Lock 等高级同步机制，在编译和运行时由 JVM 自动插入适当的内存屏障，来实现读写屏障效果。
volatile 字段如何触发读写屏障
对 volatile 变量的每次读操作，JVM 会在其前插入一个 LoadLoad + LoadStore 屏障（即读屏障），确保该读不会被重排序到它前面的任何读写操作之后；每次写操作后插入 StoreStore + LoadStore 屏障（即写屏障），保证该写不会被重排序到它后面的任何读写操作之前，并强制将缓存写回主内存。
- volatile 读 → 插入读屏障：禁止后续读写操作上移到该读之前
- volatile 写 → 插入写屏障：禁止前面读写操作下移到该写之后，且刷新本地缓存
- 注意：volatile 写还隐含 StoreLoad 屏障（在部分处理器如 x86 中由 lock 指令天然提供），用于防止读写重排序跨越 volatile 写
synchronized 块如何隐式使用内存屏障
进入 synchronized 块（monitorenter）时，JVM 插入读屏障（类似 LoadLoad + LoadStore），清空当前线程本地缓存，强制从主内存重新加载共享变量；退出时（monitorexit）插入写屏障（StoreStore + StoreLoad），把修改刷回主内存，并保证临界区内所有写对其他线程可见。
- 加锁成功后，相当于执行一次“获取屏障”（acquire fence）
- 释放锁前，相当于执行一次“释放屏障”（release fence）
- 这种 acquire-release 语义构成了 happens-before 关系，是 JMM 可见性与有序性的核心保障
JVM 如何根据平台选择具体屏障指令
不同 CPU 架构对内存序的支持不同（如 x86 是强序，ARM/Alpha 是弱序），JVM 在生成本地代码时会将抽象屏障映射为对应指令：
- x86 上，LoadLoad / LoadStore / StoreStore 多数无需显式指令（硬件保证），但 StoreLoad 需用 lock addl $0, (%rsp) 或 mfence
- ARMv7+ 使用 dmb ish 实现 full barrier，dmb ishld 实现读屏障等
- HotSpot 的 OrderAccess 类封装了跨平台屏障原语，供 JIT 和解释器调用
普通变量读写为什么没有屏障保障
非 volatile、非同步的普通字段读写，JIT 编译器可能做重排序优化（如指令重排、寄存器缓存、写合并），且 CPU 可能延迟写入主存。此时没有内存屏障约束，导致：
- 一个线程的写，另一个线程可能永远看不到（缓存未刷新 + 无 happens-before）
- 读操作可能看到“半初始化”对象（如未完成构造的 final 字段被提前读取）
- 看似顺序的代码，在多核上实际执行顺序不可预测
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
