volatile写操作触发storestore和storeload屏障：前者确保其前所有普通写不重排到之后，后者阻止其后任意读操作提前执行。
volatile 写操作触发哪些内存屏障？
Java 编译器和 JVM 在生成 volatile 变量的写指令时，会在其后插入 StoreStore 和 StoreLoad 屏障。这两个屏障不是 Java 代码写的，而是 JVM 在字节码层面（如 putstatic 或 putfield）或 JIT 编译为机器码时注入的 CPU 指令（如 x86 的 mfence、ARM 的 dmb ish）。
关键点在于：StoreStore 确保该 volatile 写之前的所有普通写（assign → store）不会被重排到它之后；StoreLoad 则进一步阻止该写与后续任意读操作（包括非 volatile 读）乱序——这是 DCL 单例中防止“对象未初始化就返回引用”的核心机制。
- 仅对 volatile 字段本身生效，不影响其他字段的重排逻辑
- 屏障类型由 JVM 根据目标平台自动选择，开发者无法手动指定
- 不阻塞线程执行，只约束指令顺序；这点和
synchronized的互斥锁有本质区别
volatile 读操作插入了什么屏障？
volatile 读（如 getstatic / getfield）前会插入 LoadLoad 和 LoadStore 屏障。其中 LoadLoad 保证该读之前的所有读操作不会被重排到它之后；LoadStore 则防止该读与后续任意写操作交换顺序。
典型场景是：线程 A 写入 flag = true（volatile），线程 B 读取 flag 为 true 后访问某个对象字段。JMM 要求 B 必须看到 A 在写 flag 之前对该对象字段所做的所有修改——这个“看到”依赖的就是 LoadLoad + StoreLoad 的组合屏障链。
- 读屏障不保证“读到最新值”的时机，只保证一旦读到，其前置依赖也已同步完成
- 没有
LoadLoad，编译器可能把后续某个非 volatile 字段读提前到 volatile 读之前，导致读到过期值 - ARM/PowerPC 等弱一致性架构下，
LoadStore尤其关键；x86 因自身内存模型较强，部分屏障会被优化掉
为什么 volatile 不能靠 happens-before 推导出禁止重排？
happens-before 是 JMM 的高层语义规则，用于定义操作间的偏序关系；而内存屏障是底层实现手段。你不能从“volatile 写 happens-before 后续 volatile 读”这条规则反推出具体插入哪类屏障——因为同一条 happens-before 关系，不同硬件平台可能用不同屏障组合实现。
比如在 x86 上，StoreLoad 屏障开销大，JVM 可能用更轻量的 lfence + 写缓冲刷出策略替代；而在 ARMv8 上则必须用 dmb ish 才能保证跨核可见性。所以分析禁止重排，必须落到具体屏障语义，而非仅停留在 happens-before 表述上。
- 写 volatile 不等于“立即刷回主内存”，而是“确保 store/write 顺序 + 插入屏障”
- happens-before 是结果，屏障是手段；混淆二者容易误判多线程行为边界
- JSR-133 规范只规定语义，不规定实现；实际屏障插入由 HotSpot 的
OrderAccess类控制
用 javap 看不到内存屏障，怎么验证？
javap 输出的是字节码，屏障指令在 JIT 编译阶段才生成。要确认是否生效，得看最终生成的汇编：
启动 JVM 加上 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=print,*YourClass.yourMethod，然后观察 volatile 写/读附近是否有 mfence、lock addl $0x0,(%rsp)（x86）或 dmb ish（ARM）等指令。
- 没开启 JIT 或方法未被热点编译时，可能走解释执行路径，屏障表现为内存栅栏调用（如
Unsafe.storeFence()） - 使用
VarHandle替代 volatile 字段时，屏障行为一致，但需显式调用setRelease/getAcquire - 注意：JIT 优化可能合并多个 volatile 访问，屏障也可能被折叠，不能仅凭一次汇编断言全局行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
