volatile写插入StoreStore+StoreLoad屏障，确保之前所有普通写不重排到其后、其后读操作不提前到之前；读插入LoadLoad+LoadStore屏障，禁止后续读写重排到其前。
Java 中指令重排序不是靠“手动插入屏障”来禁止的，而是由 JVM 在编译字节码为机器码时，根据语义自动插入内存屏障（Memory Barrier），从而约束编译器和 CPU 的重排行为。关键在于：volatile 读写、锁释放与获取、线程启动/结束等操作，会触发 JVM 插入特定类型的屏障，进而限制相邻指令的执行顺序。
volatile 写操作如何禁止重排序
对 volatile 变量的写，JVM 会插入 StoreStore + StoreLoad 屏障组合：
- StoreStore：确保该写之前的所有普通写操作，不会被重排到它之后
- StoreLoad：确保该写之后的任何读操作，不会被提前到它之前执行
- 例如：a = 1; flag = true;（flag 是 volatile），那么 a=1 一定在 flag=true 之前完成，并对其他线程可见——这正是通过 StoreStore 和后续的 volatile 读的 LoadLoad 屏障共同保障的
volatile 读操作如何禁止重排序
对 volatile 变量的读，JVM 会插入 LoadLoad + LoadStore 屏障组合：
- LoadLoad：确保该读之前的所有读操作，不会被重排到它之后
- LoadStore：确保该读之后的所有写操作，不会被重排到它之前
- 例如：if (flag) { return data; }（flag 是 volatile），data 的读取就不会被编译器或 CPU 提前到 flag 判断之前，避免读到未初始化的数据
JVM 屏障类型与硬件映射关系
JVM 规范定义了四类逻辑屏障（LL、SS、LS、SL），但不暴露给开发者；实际执行时，JVM 会按目标 CPU 架构翻译成对应指令：
立即学习“Java免费学习笔记（深入）”；
- x86 平台：volatile 写常编译为 lock xchg（隐含全屏障），volatile 读为普通 mov（因 x86 内存模型较强，读本身自带 LoadLoad+LoadStore 效果）
- ARM 平台：必须显式插入 dmb ish（inner shareable domain 内存屏障）来实现同等语义
- 这些底层指令由 JVM 自动选择，开发者无法控制或感知，也不需要关心具体汇编形式
不是所有重排序都能靠 volatile 拦住
内存屏障只约束“屏障两侧”的指令，不能保证跨屏障的全局有序：
- volatile 只能保障对该变量自身的读写建立 happens-before 关系，不能让无关变量的操作也获得顺序保证
- 比如：x = 1; flag = true; y = 2;（flag volatile），y=2 可能被重排到 flag=true 之前，只要它不违反 StoreStore 约束（即不越过 flag 写之前的其他写）
- 复合操作如 count++ 仍会出错，因为屏障不覆盖“读-改-写”整个序列，只保护单次读或单次写
