happens-before

happens-before 是JMM最核心的概念。对应Java程序员来说，理解happens-before是理解JMM的关键。

一、JMM 的设计

从JMM设计者的角度，在设计JMM时，需要考虑两个关键因素：

• 程序员对内存模型的使用。程序员希望内存模型易于理解、易于编程。程序员希望基于一个强内存模型来编写代码。

• 编译器和处理器对内存模型的实现。编译器和处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化来提高性能。编译器和处理器希望实现一个弱内存模型。

由于这两个因素互相矛盾，所以JSR-133专家组在设计JMM时的核心目标就是找到一个好的平衡点：一方面，要为程序员提供足够强的内存可见性保证；另一方面，对编译器和处理器的限制要尽可能地放松。

还是以计算圆的面积为例：

double pi = 3.14;　　    // A
double r = 1.0;　　　　   // B
double area = pi * r * r;　// C

上面计算圆的面积的示例代码存在3个happens-before关系：

1. A happens-before B。
2. B happens-before C。
3. A happens-before C。

在3个happens-before关系中，2和3是必需的，但1是不必要的。因此，JMM把happens-before
要求禁止的重排序分为了下面两类：

• 会改变程序执行结果的重排序。
• 不会改变程序执行结果的重排序。

JMM对这两种不同性质的重排序，采取了不同的策略：

• 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。
• 对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）。

二、happens-before 的定义

JSR-133 使用 happens-before 的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以是在不同线程之间。因此，JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证。

《JSR-133:Java Memory Model and Thread Specification》对 happens-before 关系的定义如下：

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

• 2）两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照 happens-before 关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。

上面的1）是JMM对程序员的承诺。 从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！

上面的2）是JMM对编译器和处理器重排序的约束原则。 正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。

三、happens-before 规则

《JSR-133:Java Memory Model and Thread Specification》定义了如下happens-before规则。

• 1）程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
• 2）监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
• 3）volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
• 4）传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
• 5）start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的
  ThreadB.start()操作happens-before于线程B中的任意操作。
• 6）join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作
  happens-before于线程A从ThreadB.join()操作成功返回。

1. volatile 变量规则

volatile 写-读建立的happens-before关系图：

• 1 happens-before 2 和 3 happens-before 4 由程序顺序规则产生。由于编译器和处理器都要遵守as-if-serial语义，也就是说，as-if-serial语义保证了程序顺序规则。因此，可以把程序顺序规则看成是对as-if-serial语义的“封装”。

• 2 happens-before 3 是由volatile规则产生。前面提到过，对一个volatile变量的读，总是能看到（任意线程）之前对这个volatile变量最后的写入。因此，volatile 的这个特性可以保证实现
  volatile 规则。

• 1 happens-before 4 是由传递性规则产生的。这里的传递性是由 volatile 的内存屏障插入策略和volatile的编译器重排序规则共同来保证的。

2. start() 规则

假设线程A在执行的过程中，通过执行ThreadB.start()来启动线程B；同时，假设线程A在执行ThreadB.start()之前修改了一些共享变量，线程B在开始执行后会读这些共享变量：

• 1 happens-before 2由程序顺序规则产生。
• 2 happens-before 4由start()规则产生。
• 1 happens-before 4 是由传递性规则产生的。这实意味着，线程A在执行ThreadB.start()之前对共享变量所做的修改，接下来在线程B开始执行后都将确保对线程B可见。

3. join() 规则

假设线程A在执行的过程中，通过执行ThreadB.join()来等待线程B终止；同时，假设线程B在终止之前修改了一些共享变量，线程A从ThreadB.join()返回后会读这些共享变量：

• 2 happens-before 4由join()规则产生；
• 4 happens-before 5由程序顺序规则产生。
• 2 happens-before 5 是由传递性规则产生的。这意味着，线程A执行操作ThreadB.join()并成功返回后，线程B中的任意操作都将对线程A可见。

happens-before 是一种约定，也是一种规范。程序员依靠这个来编写线程安全的代码，虚拟机则在底层实现上来满足这种要求，给人的感觉它就是这么做的，但它是基于性能最优来提供这种保障。