写在前面

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

从 JDK 5 开始，Java 使用新的 JSR-133 内存模型（除非特别说明，本文针对的都是JSR-133 内存模型）。JSR-133 使用 happens-before 的概念来阐述操作之间的内存可见性。

在 JMM 中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必 须要存在 happens-before 关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。

与程序员密切相关的 happens-before 规则如下。

• 程序顺序规则：一个线程中的每个操作，happens-before 于该线程中的任意后续操作。
• 监视器锁规则：对一个锁的解锁，happens-before 于随后对这个锁的加锁。
• volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个volatile 域的读。
• 传递性：如果 A happens-before B，且 B happens-before C，那么 A happens-before C。

**注意！**两个操作之间具有 happens-before 关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。

JMM 的设计

首先，让我们来看 JMM 的设计意图。从 JMM 设计者的角度，在设计 JMM 时，需要考虑两个关键因素。

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

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

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

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

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

• A happens-before B。
• B happens-before C。
• A happens-before C。

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

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

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

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

总结

（1）JMM 向程序员提供的 happens-before 规则能满足程序员的需求。JMM 的happens-before 规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证（有些内存可见性保证其实并不一定真实存在，比如上面的 A happens-before B）。

（2）JMM 对编译器和处理器的束缚已经尽可能少。从上面的分析可以看出，JMM 其 实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。例如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再如，如果编译器经过细致的分析后，认定一个 volatile 变量只会被单个线程访问，那么编译器可以把这个 volatile 变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

happens-before 的定义

happens-before 的概念最初由 Leslie Lamport 在其一篇影响深远的论文（《Time，Clocks andthe Ordering of Events in a Distributed System》）中提出。Leslie Lamport 使用happens-before 来定义分布式系统中事件之间的偏序关系（partial ordering）。Leslie Lamport 在这篇论文中给出了一个分布式算法，该算法可以将该偏序关系扩展为某种全序关系。

JSR-133 使用 happens-before 的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以是在不同线程之间。因此，JMM 可以通过 happens-before 关系向程序员提供跨线程的内存可见性保证（如果 A 线程的写操作 a 与 B 线程的读操作 b 之间存在 happens-before 关系，尽管 a 操作和 b 操作在不同的线程中执行，但JMM 向程序员保证 a 操作将对 b 操作可见）

《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 其 实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。JMM 这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变（即执行结果不能被改变）。因此，happens-before 关系本质上和 as-if-serial 语义是一回事。

as-if-serial 语义

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

1. as-if-serial 语义保证单线程内程序的执行结果不被改变，happens-before 关系保证正确同步的多线程程序的执行结果不被改变。
2. as-if-serial 语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before 关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按 happens-before 指定的顺序来执行的。
3. as-if-serial 语义和 happens-before 这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

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 写-读建立的 happens-before 关系图：

1. 1 happens-before 2 和 3 happens-before 4 由程序顺序规则产生。由于编译器和处理器都要遵守 as-if-serial 语义，也就是说，as-if-serial 语义保证了程序顺序规则。因此，可以把程序顺序规则看成是对 as-if-serial 语义的“封装”。
2. 2 happens-before 3 是由 volatile 规则产生。前面提到过，对一个 volatile 变量的读，总是能看到（任意线程）之前对这个 volatile 变量最后的写入。因此，volatile 的这个特性可以保证实现 volatile 规则。
3. 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 可见。

参考资料

《java并发编程艺术》