volatile写操作必须插入storestore+storeload屏障：storestore确保其前所有普通写不重排到之后，storeload阻止其后任意读操作提前执行。
volatile写操作必须插入StoreStore + StoreLoad屏障
OpenJDK在生成字节码对应机器指令时，对volatile字段的写入（如assign后）会强制插入两类内存屏障：StoreStore确保前面所有普通写不被重排到该volatile写之后；StoreLoad则防止该写之后的任意读被提前执行——这是避免“写后立即读却看不到之前写”的关键。x86平台虽用lock xchg隐含全屏障语义，但JVM仍按JMM规范映射为这两类逻辑屏障，以保证跨CPU架构（如ARM）行为一致。
volatile读操作触发LoadLoad + LoadStore屏障
每次读volatile变量前，JVM插入LoadLoad屏障，禁止后续读操作上移；再加LoadStore屏障，阻止后续写操作上移。这不只是“读得新”，更是为了约束代码顺序：比如if (flag) { return data; }中，flag是volatile，那data的读就不会被编译器或CPU提到flag判断之前。常见错误是以为只要读了volatile变量，它前面所有写就一定对其他线程可见——其实不行，必须依赖StoreLoad屏障兜底，而该屏障只在写端生效。
不插屏障就破环JMM的happens-before契约
- Java 5起，
volatile写与后续任意线程的volatile读之间构成happens-before关系，这是JMM的硬性保证 - 若底层不插屏障，仅靠普通读写，编译器可能重排、CPU缓存可能滞留旧值、MESI协议也无法自动同步未标记的字段
- OpenJDK通过
OrderAccess::storeload()等内联函数调用，在不同CPU架构下适配对应汇编指令（x86用lock前缀，ARM用dmb ish），把抽象语义落地为硬件可执行的同步点
Unsafe.storeFence()不能替代volatile写
有人试图用Unsafe.storeFence()手动插屏障来模拟volatile语义，但这是危险的：该API无JMM语义保证，不触发store/write原子链，也不强制刷新工作内存副本；JDK 17已限制Unsafe公开使用，且不同版本行为可能突变。真正需要的是语义完整的一致性契约，而不是零散的硬件指令控制——这正是volatile由JVM统一管理屏障的根本原因。
volatile，读就能看到所有之前的写”。它只保证对它自身的读写有序，不构成对其他非volatile变量的全局栅栏。
