指令重排序是编译器、处理器和内存系统为优化性能而调整执行顺序的行为，单线程下符合as-if-serial语义，多线程中需volatile、synchronized等机制保障有序性与可见性。
指令重排序是编译器或处理器在不改变单线程程序语义的前提下，为提升执行效率而调整指令实际执行顺序的行为。它本身不是Bug，而是现代软硬件协同优化的必然结果；但一旦进入多线程环境，缺乏同步机制时，就可能引发变量读取错乱、逻辑失效等隐蔽问题。
指令重排序的三类来源
重排序不是凭空发生的，主要来自三个层面：
-
编译器优化重排：Java源码编译为字节码时，Javac或JIT可能交换无依赖的相邻语句。例如
a = 1; flag = true;可能被重排为flag = true; a = 1;，单线程下结果不变，但其他线程可能先看到flag == true却读到a == 0。 - 处理器指令级重排：CPU采用乱序执行（Out-of-Order Execution）提高流水线利用率。只要两条指令不共享寄存器或内存地址，就可能调换执行次序，比如写操作被延迟、读操作被提前。
- 内存系统重排：由于CPU缓存、写缓冲区（Store Buffer）和无效化队列（Invalidate Queue）的存在，一个线程的写入对另一线程的可见性存在延迟，“看起来”就像读写顺序被颠倒了——这属于“伪重排序”，但效果等同于真实重排。
重排序必须遵守的底线：as-if-serial语义
所有重排序都必须满足一个前提：在单线程视角下，程序行为与按代码顺序执行的结果完全一致。这是硬性约束，不是可选项。
关键点在于：数据依赖性不可破坏。以下三类操作之间禁止重排：
立即学习“Java免费学习笔记（深入）”；
- 写后读（
a = 1; int x = a;） - 写后写（
a = 1; a = 2;） - 读后写（
int x = a; a = 3;）
而像 int x = 1; int y = 2; 这类彼此无关的操作，重排完全合法，且无法被本线程察觉。
如何控制重排序：内存屏障与volatile语义
Java不提供直接插入硬件屏障的API，而是通过语言级机制触发JVM自动插入对应内存屏障：
- volatile变量写操作：在写入后插入StoreStore + StoreLoad屏障，禁止该写与之前/之后的普通读写重排，并强制刷新缓存到主内存。
- volatile变量读操作：在读取前插入LoadLoad + LoadStore屏障，禁止该读与之前/之后的普通读写重排，并强制从主内存或最新缓存加载值。
- synchronized块出入：隐式包含完整的内存屏障，保证临界区内外的可见性与有序性。
- final字段构造器结束：对象构造完成那一刻，对final字段的写入会插入StoreStore屏障，确保其他线程看到该对象时，final字段已正确初始化（安全发布）。
典型问题场景与验证思路
常见出问题的模式是“状态标志+数据准备”分离，例如：
危险写法：
data = 42; // 准备数据
ready = true; // 发布就绪
另一个线程可能看到
ready == true 但 data == 0，因为这两句被重排或缓存未同步。
修复方式：
– 把 ready 声明为 volatile；
– 或用 synchronized 包裹两行；
– 或使用 AtomicBoolean + 内存屏障语义。
可通过循环压力测试（如反复启停两个线程读写共享变量）复现 (0,0) 类异常结果，这是重排序存在的直接证据。
基本上就这些。理解重排序不靠死记规则，而在于抓住“单线程保序、多线程需显式同步”这个核心逻辑。
