指令重排的真实边界是as-if-serial语义与happens-before关系的双重约束：单线程内不改变执行结果，多线程间依赖同步机制建立可见性与有序性保障。
指令重排不是无边界的自由优化，而是在 as-if-serial 语义 和 happens-before 关系 双重约束下进行的。JVM 和 CPU 可以重排操作，但绝不能破坏单线程正确性，更不能违反程序员通过同步机制明确建立的内存可见性与执行顺序保证。
指令重排的真实边界在哪？
重排只发生在“对结果无影响”的前提下——即满足 as-if-serial 语义：单线程中，无论怎么重排，程序最终表现必须和按代码顺序执行一致。这意味着：
- 存在数据依赖的操作不会被重排（如
a = 1; b = a + 1;中，b = a + 1不能提前到a = 1之前） - 不存在依赖的操作可能被重排（如
a = 1; b = 2;可能交换顺序） - 跨线程场景下，仅靠 as-if-serial 不足以保证安全；必须依赖 happens-before 来划定多线程间的有效边界
happens-before 如何充当重排的“刹车”？
它不是一条具体指令，而是一组逻辑约束规则，一旦两个操作之间建立了 happens-before 关系，JVM 就必须确保：
- 它们不被重排序（有序性）
- 前一个操作对变量的修改对后一个操作可见（可见性）
典型建立方式包括：
- 程序顺序规则：同一线程内，代码靠前的操作 happens-before 靠后的操作
- volatile 规则：对 volatile 变量的写 happens-before 后续对该变量的读
- 锁规则：解锁操作 happens-before 后续对同一锁的加锁操作
- 线程启动/终止规则：start() / join() 调用建立跨线程的 happens-before 链
只要满足任一规则，JVM 就会在编译和运行时插入必要屏障，阻止违反该关系的重排。
内存屏障是 happens-before 的底层实现机制
happens-before 是抽象契约，内存屏障（Memory Barrier）才是 JVM 在字节码、JIT 编译及 CPU 层面落实该契约的具体手段。不同同步原语触发不同类型的屏障：
- volatile 写：插入 StoreStore + StoreLoad 屏障 → 确保写操作不被重排到其后，且刷新工作内存到主内存
- volatile 读：插入 LoadLoad + LoadStore 屏障 → 确保读操作不被重排到其前，且强制从主内存加载最新值
- synchronized 退出：隐含 StoreStore + StoreLoad → 释放锁前将工作内存写回主内存
- synchronized 进入：隐含 LoadLoad + LoadStore → 获取锁后清空本地缓存，强制重新读取共享变量
这些屏障直接干预 CPU 的乱序执行和缓存一致性协议（如 MESI），把高级语言的语义映射到底层硬件行为上。
常见误判：没有 happens-before 就没有安全保证
如果两个操作之间没有任何 happens-before 路径连接（比如不同线程中无锁、无 volatile、无 start/join 的普通读写），那么：
- JVM 允许任意重排（包括构造对象时的指令重排导致 DCL 单例失效）
- 线程可能看到过期值、部分初始化对象、甚至“时间倒流”的现象（如先看到 flag = true，后看到 x = 0）
- 这不是 bug，而是 JMM 的明确设计——它把控制权交还给程序员，由你决定何时建立同步边界
换句话说，happens-before 不是默认存在的，而是需要你主动“铺设”的路径。
