Java指令重排与CPU内存重排的关联、归属及平台特性相关咨询

我们常说的「指令重排」本质是性能优化的手段，通常分为两类：

• 编译器层面重排：javac、JIT即时编译器在不改变单线程执行结果的前提下，调整指令执行顺序提升执行效率
• CPU硬件层面重排：现代CPU为了最大化利用运算单元，会对指令乱序执行，属于硬件层面的优化

而你提到的其他概念属于同一问题域的不同环节：

• 内存重排：是CPU缓存、存储子系统带来的内存访问顺序和指令执行顺序不一致的现象，本质是多核心缓存一致性协议的实现差异导致
• Java内存模型（JMM）：是JVM规范定义的一套抽象规则，用来屏蔽不同硬件、操作系统的内存访问差异，明确了多线程场景下哪些重排是允许的、哪些是禁止的，还通过volatile、synchronized等关键字给开发者提供了控制重排的手段

最终多线程场景下遇到的违反直觉的执行结果，基本都是编译器重排、CPU指令重排、内存重排三者共同作用的结果，指令重排只是其中一个环节的诱因。

所有支持多线程、搭载优化编译器、运行在现代多核心CPU上的编程语言都会遇到同类问题，甚至C/C++这类无官方统一定义内存模型的语言，问题暴露的概率更高：

• 这类语言没有类似JMM的上层抽象，开发者需要直接适配不同CPU的内存模型，很容易写出CPU架构相关的并发Bug
• Java的JMM已经通过happen-before规则帮开发者屏蔽了大量底层细节，反而降低了这类问题的出现概率。

• 不同CPU的内存模型强弱不同：x86属于典型的强内存模型（TSO模型），默认禁止了绝大多数类型的内存重排，仅允许store-load类型的重排，所以很多复现内存重排问题的代码在x86设备上跑几万次都不会触发异常
• ARM、RISC-V等架构属于弱内存模型，允许更多类型的内存重排，同样的复现代码在这类架构的设备上大概率跑几次就能触发问题
• 哪怕是x86设备，仍然可能遇到编译器层面的重排问题：比如你没有给共享变量加volatile修饰，JIT编译器可能直接把变量值缓存到寄存器里，就算其他线程修改了内存中的变量值，当前线程也感知不到，这种问题和CPU架构无关，任何平台都可能出现。

内容的提问来源于stack exchange，提问作者Gonen I