JMM之重排序&Happens-Before

并发编程中，需要处理两个关键问题：

线程之间如何通信？—共享内存+消息传递
线程之间如何同步？

java的并发采用的是共享内存的方式，线程之间共享-“共享变量”的公共状态，通过写-读内存来隐式的进行通信。

java内存模型的抽象

在java中，所有的实例、静态变量、数组元素存储在堆内存中，堆内存在线程之间共享。

而局部变量Local variables、方法定义参数（formal method parameters，个人理解为形参）、异常处理器参数（exception handler parameters）不会在线程之间共享，所以不会有内存可见性问题，也不受内存模型的影响。

java线程之间的通信由JMM（Java Memory Model）来控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

共享变量存储在主内存中，每个线程的本地内存中存储了读/写共享变量的副本。

主内存：就是jvm本身的堆内存空间

工作内存/本地内存：一个抽象的概念，本身并不真实存在，涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

重排序

分三种类型，按可能顺序执行如下：

编译器优化的重排序，不改变单线程程序语义—即不改变执行结果，可以由编译器jit来重新组织编译后的代码顺序
指令级并行的重排序，目前cpu都采用了指令级并行技术（Instruction-Level-Parallelism）来将多条指令重叠执行，如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序
内存系统的重排序，由于处理器使用缓存和写缓冲区，这使得加载和存储操作看上去可能是在乱序执行

2、3属于处理器级别重排。

重排序可能会导致多线程程序出现内存可见性问题：

对于编译器重排序，jmm的重排序规则会禁止特定类型的重排。
对于处理器重排，jmm会要求java编译器在生成指令序列时，插入特性类型的内存屏障，memory barriers（或称之为memery fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

内存屏障

JMM把内存屏障分为以下四类：内存屏障保证之前和之后的代码不会被重排序。

LoadLoad Barriers

示例：

load_code_block_1;

LoadLoad;

loac_code_block_2;

用于数据的读场景，确保load_code_block_1语句中数据的装载的执行，之前于执行load_code_block_2及后续装载指令的装载。
StoreStore Barriers

示例：

Store_code_block_1;

StoreStore;

Store_code_block_2;

用于数据的写场景，确保store_code_block1对其他处理器可见（刷回到主内存），之前于store_code_block_2及后续存储指令的存储。
LoadStore Barriers

示例：

load_code_block_1;

LoadStore;

Store_code_block_2;

用于数据的读场景，确保load_code_block_1的数据装载，之前于store_code_block_2及所有后续存储指令刷新到内存。
StoreLoad Barriers

示例：

Store_code_block_1;

StoreLoad;

Load_code_block_2;

用于数据的写场景，确保store_code_block1对共享变量的处理对其他processor处理器可见（也就是刷新到内存），之前于Load_code_block2及所有后续装载指令的装载。

StoreLoad Barriers会使该屏障之前的所有内存访问指令（包含load及store，也就读和写）完成之后，才执行该屏障之后的所有内存操作指令。

storeLoad是一个全能型的屏障，现在大多数处理器都支持该屏障。执行它的开销会很昂贵，因为当前处理器通常需要把写缓冲区中的数据全部刷新到内存中。

Happens-before

Jsr-133使用happens-before的概念来阐述操作之间的内存可见性。

在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作必须存在happens-before的关系。

这里的两个操作，既可以是同一个线程，也可以是不同线程之间。

happens-before的4个规则：

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。

int a1 = 1； — 操作1

int a2 = 2; — 操作2

那么操作1 happens-before 操作2
监视器锁规则：对一个监视器的解锁，happens-before于随后对这个监视器的加锁

监视器—> 可以认为就是一个共享变量

也就是说，对一个共享变量的解锁，happens-before于随后对这个共享变量的加锁
volatile变量规则：对一个volatile变量的写，happens-before于任意后续对这个volatile变量的读。

其实跟规则2很类似，volatile的写，相当于锁的释放，会把最新值刷到主内存中。而volatile的读，则跟加锁类似，会将本地内存清空，读取主内存中最新的值。
传递性：如果A happens-before B, B happens-before C,那么A happens-before C.

但是：两个操作之间具有happens-before关系，A happens-before B,并不意味着A一定要B之前执行。

happens-before 仅要求前一个操作执行的结果对后一个操作可见，且前一个操作按顺序排在第二个操作之前

The first is visible to and ordered before the second.

不过：也就是A及A之前的操作对共享变量的影响，都对B可见，这句话同时应用到了规则2、3和4。但是，如果A和B之间没有任何依赖，那么A和B其实是可以重排序的，这个跟happens-before没什么冲突。也就意味着，A happens-before B，但是可能B先执行完了，因为A的结果，B并不关心，也不影响整个程序的结果。

happens-before规则只是对于java程序员来说易于理解，简单易懂，避免为了理解JMM提供的内存可见性保证，而去学习复杂的重排序规则以及对应的具体实现。

重排序—详解

数据依赖性

如果两个操作访问同一个变量，且至少其中一个操作为写操作，此时这两个操作之间就有数据依赖性。

这时候，如果重排序两个操作的执行顺序，那么执行的结果将会被改变。所以为了保证结果正确，编译器和处理器在重排序代码时，会遵守数据依赖性，不会重排存在数据依赖的两个操作之间的执行顺序。

不过，这里说的数据依赖性仅针对单个处理器中执行的指令序列，和单个线程中执行的操作，不同处理器和不同线程之间的数据依赖性不被编译器和处理器在重排时考虑，也无法考虑。

As-if-serial

跟上次讲的一致，在单线程语义下，重排序不会影响程序的执行结果。也就是说，对于存在数据依赖关系的操作，其实并不会进行重排序。

程序顺序规则

double pi = 3.14
double r = 1.0
double area = pi * r * r

这里有三个happens-before关系：

A： 1 happens-before 2

B: 2 happens-before 3

C: 1 happens-before 3

而这里的C是根据传导性推导出来的。

而且这里的1 和2两个操作，实际执行时，2是可以在1之前执行（重排序后），也就是虽然A这个happens-before存在，但是1和2两个操作是不一定严格按照这个顺序来执行的。

1 和 2 之间并没有数据依赖关系，而且执行结果也一样，所以虽然A这种happens-before关系存在，但是1 和 2 是可以重排序的。