你写了一段 Java 代码，编译成 class 文件后，JVM 就会一条条执行对应的字节码指令。但你有没有想过，这些指令真的是按你写的顺序一条不漏地执行的吗？其实，在很多情况下，它们早就被悄悄“调换”了位置——这就是字节码指令重排序。
代码顺序 ≠ 执行顺序
比如你在写一个简单的计数器逻辑：
int a = 0;
int b = 0;
a = 1;
b = 2;从语义上看，a 赋值在前，b 赋值在后。但在 JVM 执行时，这两条赋值指令完全可能被交换顺序。因为它们之间没有依赖关系，不影响最终结果，JVM 和底层硬件为了提升效率，就可能重新排列它们的执行次序。
重排序不只是字节码的事
指令重排序其实发生在多个层面：编译器优化、JVM 字节码处理、CPU 指令并行执行，甚至内存访问层面都有可能发生。而“字节码指令重排序”特指在 JVM 解释或 JIT 编译过程中，对字节码序列进行的逻辑等价但顺序不同的调整。
举个例子，下面这段代码：
int x, y, r1, r2;
x = 1; // 指令1
r1 = y; // 指令2
y = 1; // 指令3
r2 = x; // 指令4如果这四条指令分布在两个线程中，并且没有同步控制，那么由于重排序的存在，r1 和 r2 都有可能读到 0。这听起来反直觉，但正是因为指令2和指令1之间没有数据依赖，JVM 可能会先执行指令2再执行指令1，造成“读到了旧值”的现象。
为什么允许重排序？
核心原因就一个：性能。现代处理器为了充分利用流水线、缓存和多核能力，必须打破严格的顺序执行模型。只要程序的最终结果在单线程下看起来“像是”按顺序执行的（这就是所谓的“as-if-serial”语义），JVM 就可以自由地重排指令。
比如一个方法里先计算一个局部变量，再读取某个静态字段，这两个操作互不干扰，JVM 完全可以把读字段的操作提前，避免后续的等待延迟。
什么时候会出问题？
重排序在单线程环境下不会暴露问题，但在多线程场景下就可能引发数据竞争。比如你在一个线程中初始化对象，另一个线程判断引用是否为空来决定是否使用它。如果构造函数中的字段赋值被重排序到对象引用赋值之后，另一个线程就可能看到一个“半初始化”的对象。
这时候，就需要靠 volatile、synchronized 或 final 这些关键字来建立“内存屏障”，阻止特定的重排序行为。
看得到的字节码，看不到的调度
你可以用 javap -c 查看 class 文件的字节码，看到的是编译器输出的原始顺序。但这并不等于运行时的实际执行顺序。JIT 编译器在将字节码转为机器码的过程中，还会做进一步的优化和重排。
就像快递分拣中心的传送带，包裹到达的顺序和最终装车的顺序可能完全不同，只要最终送达客户手里没错就行。JVM 也一样，它只保证你看不到错误的结果，但过程可以灵活调度。
理解字节码指令重排序，不是为了去操控它，而是为了明白：你以为的顺序，未必是系统执行的顺序。尤其是在写并发程序时，别依赖“看起来应该没问题”的直觉，而是要靠同步机制来建立确定性。