as-if-serial

as-if-serial 语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime 和处理器都必须遵守 as-if-serial 语义。

为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

double pi = 3.14; // Adouble r = 1.0; // Bdouble area = pi * r * r; // C

A 和 C 之间存在数据依赖关系，同时 B 和 C 之间也存在数据依赖关系。因此在最终执行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的结果将会被改变）。但 A 和 B 之间没有数据依赖关系，编译器和处理器可以重排序 A 和 B 之间的执行顺序。

happens-before

从 JDK 5 开始，JMM 使用 happens-before 的概念来阐述多线程之间的内存可见性。在 JMM 中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before 关系。 happens-before 和 JMM 关系如下图：

happens-before 原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。下面我们就一个简单的例子稍微了解下 happens-before ：

i = 1; //线程 A 执行 j = i ; //线程 B 执行

j 是否等于 1 呢？假定线程 A 的操作（i = 1）happens-before 线程 B 的操作（j = i）,那么可以确定线程 B 执行后 j = 1 一定成立，如果他们不存在 happens-before 原则，那么 j = 1 不一定成立。这就是 happens-before 原则的威力。

happens-before 原则定义如下：

1. 如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

2. 两个操作之间存在 happens-before 关系，并不意味着一定要按照 happens-before 原则制定的顺序来执行。如果重排序之后的执行结果与按照 happens-before 关系来执行的结果一致，那么这种重排序并不非法。

下面是 happens-before 原则规则：

1.程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；

2.锁定规则：一个 unLock 操作先行发生于后面对同一个锁的 lock 操作；

3.volatile 变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；

4.传递规则：如果操作 A 先行发生于操作 B，而操作 B 又先行发生于操作 C，则可以得出操作 A 先行发生于操作 C；

5.线程启动规则：Thread 对象的 start()方法先行发生于此线程的每个一个动作；

6.线程中断规则：对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；

7.线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过 Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；

8.对象终结规则：一个对象的初始化完成先行发生于他的 finalize()方法的开始；

我们来详细看看上面每条规则（摘自《深入理解 Java 虚拟机第 12 章》）：

程序次序规则：一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。

锁定规则：这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行 unlock 操作后面才能进行 lock 操作。

volatile 变量规则：这是一条比较重要的规则，它标志着 volatile 保证了线程可见性。通俗点讲就是如果一个线程先去写一个 volatile 变量，然后一个线程去读这个变量，那么这个写操作一定是 happens-before 读操作的。

传递规则：提现了 happens-before 原则具有传递性，即 A happens-before B , B happens-before C，那么 A happens-before C

线程启动规则：假定线程 A 在执行过程中，通过执行 ThreadB.start()来启动线程 B，那么线程 A 对共享变量的修改在接下来线程 B 开始执行后确保对线程 B 可见。

线程终结规则：假定线程 A 在执行的过程中，通过制定 ThreadB.join()等待线程 B 终止，那么线程 B 在终止之前对共享变量的修改在线程 A 等待返回后可见。

上面八条是原生 Java 满足 Happens-before 关系的规则，但是我们可以对他们进行推导出其他满足 happens-before 的规则：

1.将一个元素放入一个线程安全的队列的操作 Happens-Before 从队列中取出这个元素的操作

2.将一个元素放入一个线程安全容器的操作 Happens-Before 从容器中取出这个元素的操作

3.在 CountDownLatch 上的倒数操作 Happens-Before CountDownLatch#await()操作

4.释放 Semaphore 许可的操作 Happens-Before 获得许可操作

5.Future 表示的任务的所有操作 Happens-Before Future#get()操作

6.向 Executor 提交一个 Runnable 或 Callable 的操作 Happens-Before 任务开始执行操作

这里再说一遍 happens-before 的概念：如果两个操作不存在上述（前面 8 条 + 后面 6 条）任一一个 happens-before 规则，那么这两个操作就没有顺序的保障，JVM 可以对这两个操作进行重排序。如果操作 A happens-before 操作 B，那么操作 A 在内存上所做的操作对操作 B 都是可见的。

下面就用一个简单的例子来描述下 happens-before 原则：

private int i = 0; public void write(int j ){ i = j;} public int read(){ return i;}

我们约定线程 A 执行 write()，线程 B 执行 read()，且线程 A 优先于线程 B 执行，那么线程 B 获得结果是什么？；我们就这段简单的代码一次分析 happens-before 的规则（规则 5、6、7、8 + 推导的 6 条可以忽略，因为他们和这段代码毫无关系）：

• 由于两个方法是由不同的线程调用，所以肯定不满足程序次序规则；

• 两个方法都没有使用锁，所以不满足锁定规则；

• 变量 i 不是用 volatile 修饰的，所以 volatile 变量规则不满足；

• 传递规则肯定不满足；

所以我们无法通过 happens-before 原则推导出线程 A happens-before 线程 B，虽然可以确认在时间上线程 A 优先于线程 B 指定，但是就是无法确认线程 B 获得的结果是什么，所以这段代码不是线程安全的。那么怎么修复这段代码呢？满足规则 2、3 任一即可。

happens-before 原则是 JMM 中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。