volatile能禁止重排序是因为JMM为其写操作插入StoreStore+StoreLoad屏障、读操作插入LoadLoad+LoadStore屏障，强制限制编译器和CPU重排；普通变量无此约束。
为什么 volatile 能禁止重排序，但普通变量不能
因为 JMM 对 volatile 变量施加了特殊的内存语义：写操作后插入 StoreStore + StoreLoad 屏障，读操作前插入 LoadLoad + LoadStore 屏障。这些屏障不是 Java 代码，而是 JVM 在生成字节码或 JIT 编译时，向底层指令流中注入的内存栅栏（Memory Barrier），强制限制编译器和 CPU 的重排自由度。
- 普通变量的读写，JMM 不做任何顺序约束——编译器可把
a = 1和flag = true换序，CPU 也可能让 storeflag先于 storea刷出到缓存 -
volatile写操作会“冲刷”Store Buffer，确保之前所有写对其他核可见；volatile读操作会“清空”Invalidate Queue，并强制从缓存一致性协议（如 MESI）中拉取最新值 - 注意：
volatile仅禁止与它自身存在 happens-before 关系的操作被重排，不保证复合操作（如counter++）原子性
双重检查锁（DCL）里不加 volatile 会发生什么
典型错误是单例对象构造完成前，引用就被其他线程看到——即“部分初始化”问题。根源在于：对象创建包含三步：memory allocate → ctor call → assign reference。JIT 可能将第三步提前，而 volatile 强制这三步在语义上不可重排，且对其他线程可见。
- 现象：线程 B 调用
getInstance()得到非 null 的instance，但访问其字段时报NullPointerException或返回默认值 - 根本原因不是“没同步”，而是“同步了但重排绕过了同步边界”——synchronized 块内仍允许构造过程被重排
- 修复只需把
private static Singleton instance改为private static volatile Singleton instance，无需改逻辑
happens-before 不是执行顺序，而是可见性契约
很多人误以为 happens-before 表示“一定先执行”，其实它只规定：如果 A happens-before B，则 A 的结果对 B 是可见的。这个关系不传递执行时序，也不阻止重排，只是划定一个“安全可见边界”。
- 例如：
synchronized块解锁 happens-before 后续同锁的加锁，但两个 synchronized 块之间若无锁竞争，JVM 仍可重排它们内部指令 - 程序顺序规则（每个线程内，按代码顺序，前一条 happens-before 后一条）是唯一保障单线程语义的规则；其余规则（如 volatile 规则、传递性）都是为多线程可见性服务
- 写 final 字段的构造器结束 happens-before 构造器返回——这是
final域安全发布的底层依据，但仅对 final 字段生效，对普通字段无效
编译器重排和 CPU 重排要分开应对
编译器（javac / JIT）重排发生在字节码生成或运行时编译阶段；CPU 重排发生在指令执行时。JMM 必须双管齐下：对前者靠禁止特定优化（如禁止跨 volatile 读写的指令移动），对后者靠插入内存屏障（如 x86 的 mfence、lfence）。
- JIT 编译器看到
volatile字段访问，会禁用相关优化，比如不把循环中对 volatile 的读提升到循环外 - 在 x86 上，volatile 写自动带 StoreStore + StoreLoad 语义（因 x86 内存模型较强），但 ARM/AArch64 必须显式插入
dmb ishst和dmb ish才等效 - 别试图用
Thread.yield()或空循环“防止重排”——它们既不构成 happens-before，也不触发内存屏障，纯属无效操作
真正难的是理解：重排不是 bug，是硬件和编译器默认开启的性能开关；JMM 不是消灭重排，而是用最小代价划出可控的例外区域。一旦离开 volatile、synchronized、final 这些明确锚点，你就回到了“未定义行为”的荒野。
