一、基本概念
对于一个线程的执行代码而言，我们总是习惯性认为代码的执行总是从上到下，有序执行。
但为了提升性能，编译器和处理器通常会对指令序列进行重新排序。
Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果一致，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。
指令重排序类型
（1）编译器优化的重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
（2）指令级并行的重排序：现代处理器采用了指令级并行技术（ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
（3）内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。
指令重排序优缺点
- 优点：JVM能根据处理器特性（CPU多级缓存系统、多核处理等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度发挥机器性能。
- 缺点：指令重排序可以保证串行语义一致，但没有义务保证多线程之间的语义一致（即可能产生“脏读”）。
二、代码解读指令重排
JVM会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码
static int i; static int j; // 在某个线程内执行如下赋值操作 i = ...; j = ...;
可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是
i = ...; j = ...;
也可以是
j = ...; i = ...;
这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU 执行指令的原理来理解一下吧
三、指令级并行原理
指令重排序优化
事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回这 5 个阶段。
术语参考：
instruction fetch (IF)
instruction decode (ID)
execute (EX)
memory access (MEM)
register write back (WB)
在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，分阶段、分工正是提升效率的关键！
支持流水线的处理器
现代 CPU 支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一 条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了 指令地吞吐率。
大多数处理器包含多个执行单元，并不是所有计算功能都集中在一起，可以再细分为整数运算单元、浮点数运算单元等，这样可以把多条指令也可以做到并行获取、译码等，CPU 可以在一个时钟周期内，执行多于一条指令，IPC>1。
四、指令重排序带来的问题
4.1 诡异的结果
int num = 0; boolean ready = false; // 线程1 执行此方法 public void actor1(I_Result r) { if(ready) { r.r1 = num + num; } else { r.r1 = 1; } } // 线程2 执行此方法 public void actor2(I_Result r) { num = 2; ready = true; }
I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？
- 情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
- 情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
- 情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）
- 情况4：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加结果为 0，再切回线程2 执行 num = 2（情况4由于指令重排序出现里问题）
这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化
- 这个现象需要通过大量测试才能复现：借助 java 并发压测工具jcstress（Java Concurrency Stress）
- jmeter侧重对于接口整体的响应速度等进行测试，而JCStress框架能对某块逻辑代码进行高并发测试，更加侧重JVM，类库等领域的研究
4.2 指令重排的说明
- 指令重排序操作不会对存在数据依赖关系的操作进行重排序。比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。
- 重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变。 比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系，所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。
指令重排序在单线程模式下是一定会保证最终结果的正确性， 但是在多线程环境下，问题就出来了。
五、解决方法
volatile 修饰的变量，可以禁用指令重排
注：对于volatile禁止指令重排的原理见文章：volatile原理
import org.openjdk.jcstress.annotations.*; import org.openjdk.jcstress.infra.results.I_Result; @JCStressTest // 标记此类为一个并发测试类 @Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok") @Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!") @State // 标记此类是有状态的 public class ConcurrencyTest { int num = 0; volatile boolean ready = false;//加上 volatile 防止 修改ready操作 之前的写指令重排 @Actor public void actor1(I_Result r) { if(ready) { r.r1 = num + num; } else { r.r1 = 1; } } @Actor public void actor2(I_Result r) { num = 2; ready = true; } }
运行结果
*** INTERESTING tests Some interesting behaviors observed. This is for the plain curiosity. 0 matching test results.
思考：是否可以通过synchronized来解决该问题？
使用synchronized并不能解决有序性问题，但是如果是该变量整个都在synchronized代码块的保护范围内，那么变量就不会被多个线程同时操作，也不用考虑有序性问题！在这种情况下相当于解决了重排序问题！
