什么是指令重排？
案例
public class MemoryReorderingExample {
private static int x = 0, y = 0;
private static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
int i = 0;
while (true) {
i++;
x = 0;
y = 0;
a = 0;
b = 0;
Thread t1 = new Thread(() -> {
a = 1;
x = b;
});
Thread t2 = new Thread(() -> {
b = 1;
y = a;
});
t1.start();
t2.start();
t1.join();
t2.join();
String result = "第" + i + "次(" + x + "," + y + ")";
if (x == 0 && y == 0) {
System.out.println(result);
break;
}
}
}
}
结果
第多少多少次(0,0)
- 定义四个int类型的变量，初始化都为0。
- 定义两个线程t1、t2
- t1线程修改a和x的值
- t2线程修改b和y的值
- 分别启动两个线程。
- 正常情况下，x和y的值，会根据t1和t2线程的执行情况来决定。
- 如果t1线程优先执行，那么得到的结果是x=0、y=1。
- 如果t2线程优先执行，那么得到的结果是x=1、y=0。
- 如果t1和t2线程同时执行，那么得到的结果是x=1、y=1。
为什么？结果为什么是 0 和 0。
其实这就是所谓的指令重排序问题，假设上面的代码通过指令重排序之后，变成下面这种结构：
Thread t1=new Thread(()->{
x=b; //指令重排序
a=1;
});
Thread t2=new Thread(()->{
y=a; //指令重排序
b=1;
});
经过重排序之后，如果t1和t2线程同时运行，就会得到x=0、y=0的结果，这个结果从人的视角来看，就有点类似于t1线程中a=1的修改结果对t2线程不可见，同样t2线程中b=1的执行结果对t1线程不可见。
什么是指令重排？
指令重排序是指编译器或CPU为了优化程序的执行性能而对指令进行重新排序的一种手段，重排序会带来可见性问题，所以在多线程开发中必须要关注并规避重排序。
从源代码到最终运行的指令，会经过如下两个阶段的重排序。
第一阶段，编译器重排序，就是在编译过程中，编译器根据上下文分析对指令进行重排序，目的是减少CPU和内存的交互，重排序之后尽可能保证CPU从寄存器或缓存行中读取数据。
在前面分析JIT优化中提到的循环表达式外提（Loop Expression Hoisting）就是编译器层面的重排序，从CPU层面来说，避免了处理器每次都去内存中加载stop，减少了处理器和内存的交互开销。
第二阶段，处理器重排序，处理器重排序分为两个部分。
- 并行指令集重排序，这是处理器优化的一种，处理器可以改变指令的执行顺序。
- 内存系统重排序，这是处理器引入Store Buffer缓冲区延时写入产生的指令执行顺序不一致的问题。
扩展
什么是JIT？
1、动态编译（dynamic compilation）指的是“在运行时进行编译”；与之相对的是事前编译（ahead-of-time compilation，简称AOT），也叫静态编译（static compilation）。
2、JIT 编译（just-in-time compilation）狭义来说是当某段代码即将第一次被执行时进行编译，因而叫“即时编译”。JIT编译是动态编译的一种特例。JIT编译一词后来被泛化，时常与动态编译等价；但要注意广义与狭义的JIT编译所指的区别。
3、自适应动态编译（adaptive dynamic compilation）也是一种动态编译，但它通常执行的时机比JIT编译迟，先让程序“以某种式”先运行起来，收集一些信息之后再做动态编译。这样的编译可以更加优化。
在部分商用虚拟机中（如HotSpot），Java程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文统称JIT编译器）。
即时编译器并不是虚拟机必须的部分，Java虚拟机规范并没有规定Java虚拟机内必须要有即时编译器存在，更没有限定或指导即时编译器应该如何去实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键的指标之一，它也是虚拟机中最核心且最能体现虚拟机技术水平的部分。
由于Java虚拟机规范并没有具体的约束规则去限制即使编译器应该如何实现，所以这部分功能完全是与虚拟机具体实现相关的内容，如无特殊说明，我们提到的编译器、即时编译器都是指Hotspot虚拟机内的即时编译器，虚拟机也是特指HotSpot虚拟机。
为什么HotSpot虚拟机要使用解释器与编译器并存的架构？
尽管并不是所有的Java虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机（如HotSpot），都同时包含解释器和编译器。
解释器与编译器两者各有优势：当程序需要 迅速启动和执行 的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取 更高的执行效率 。当程序运行环境中 内存资源限制较大 （如部分嵌入式系统中），可以使用 解释器执行节约内存 ，反之可以使用 编译执行来提升效率 。此外，如果编译后出现“罕见陷阱”，可以通过逆优化退回到解释执行。
HotSpot虚拟机中内置了两个即时编译器：Client Complier和Server Complier，简称为C1、C2编译器，分别用在客户端和服务端。目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。程序使用哪个编译器，取决于虚拟机运行的模式。HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式或Server模式。
用Client Complier获取更高的编译速度，用Server Complier 来获取更好的编译质量。为什么提供多个即时编译器与为什么提供多个垃圾收集器类似，都是为了适应不同的应用场景。
编译的时间开销
解释器的执行，抽象的看是这样的：
*输入的代码 -> [ 解释器 解释执行 ] -> 执行结果
而要JIT编译然后再执行的话，抽象的看则是：
*输入的代码 -> [ 编译器 编译 ] -> 编译后的代码 -> [ 执行 ] -> 执行结果
*说JIT比解释快，其实说的是“执行编译后的代码”比“解释器解释执行”要快，并不是说“编译”这个动作比“解释”这个动作快。
JIT编译再怎么快，至少也比解释执行一次略慢一些，而要得到最后的执行结果还得再经过一个“执行编译后的代码”的过程。所以，对“只执行一次”的代码而言，解释执行其实总是比JIT编译执行要快。
怎么算是“只执行一次的代码”呢？粗略说，下面两个条件同时满足时就是严格的“只执行一次”
1、只被调用一次，例如类的构造器（class initializer，
2、没有循环
对只执行一次的代码做JIT编译再执行，可以说是得不偿失。
对只执行少量次数的代码，JIT编译带来的执行速度的提升也未必能抵消掉最初编译带来的开销。
只有对频繁执行的代码，JIT编译才能保证有正面的收益。
什么是并行指令集？
在处理器内核中一般会有多个执行单元，比如算术逻辑单元、位移单元等。
- 在引入并行指令集之前，CPU在每个时钟周期内只能执行单条指令，也就是说只有一个执行单元在工作，其他执行单元处于空闲状态；
- 在引入并行指令集之后，CPU在一个时钟周期内可以同时分配多条指令在不同的执行单元中执行。
那么什么是并行指令集的重排序呢？
如下图所示，假设某一段程序有多条指令，不同指令的执行实现也不同。
对于一条从内存中读取数据的指令，CPU的某个执行单元在执行这条指令并等到返回结果之前，按照CPU的执行速度来说它足够处理几百条其他指令，而CPU为了提高执行效率，会根据单元电路的空闲状态和指令能否提前执行的情况进行分析，把那些指令地址顺序靠后的指令提前到读取内存指令之前完成。
实际上，这种优化的本质是通过提前执行其他可执行指令来填补CPU的时间空隙，然后在结束时重新排序运算结果，从而实现指令顺序执行的运行结果。
as-if-serial语义
as-if-serial表示所有的程序指令都可以因为优化而被重排序，但是在优化的过程中必须要保证是在单线程环境下，重排序之后的运行结果和程序代码本身预期的执行结果一致，Java编译器、CPU指令重排序都需要保证在单线程环境下的as-if-serial语义是正确的。
可能有些读者会有疑惑，既然能够保证在单线程环境下的顺序性，那为什么还会存在指令重排序呢？在JSR-133规范中，原文是这么说的。
The compiler, runtime, and hardware are supposed to conspire to create the illusion of as-if-serial semantics, which means that in a single-threaded program, the program should not be able to observe the effects of reorderings.However, reorderings can come into play in incorrectly synchronized multithreaded programs, where one thread is able to observe the effects of other threads, and may be able to detect that variable accesses become visible to other threads in a different order than executed or specified in the program.
编译器、运行时和硬件应该合力创造as-if-serial语义的错觉，这意味着在单线程程序中，程序不应该能够观察到重新排序的效果。然而，重新排序可以 在不正确同步的多线程程序中发挥作用，其中一个线程能够观察其他线程的影响，并且可能能够检测到变量访问对其他线程以与程序中执行或指定的顺序不同的顺序变得可见。
as-if-serial语义允许重排序，CPU层面的指令优化依然存在。在单线程中，这些优化并不会影响整体的执行结果，在多线程中，重排序会带来可见性问题。
另外，为了保证as-if-serial语义是正确的，编译器和处理器不会对存在依赖关系的操作进行指令重排序，因为这样会影响程序的执行结果。我们来看下面这段代码：
public void execute(){
int x=10; //1
int y=5; //2
int c=x+y; //3
}
上述代码按照正常的执行顺序应该是1、2、3，在多线程环境下，可能会出现2、1、3这样的执行顺序，但是一定不会出现3、2、1这样的顺序，因为3与1和2存在数据依赖关系，一旦重排序，就无法保证as-if-serial语义是正确的。
