Java内存模型之happens-before

导读
happens-before是JMM最核心的概念。对应Java程序员来说，理解happens-before是理解JMM(Java内存模型)的关键

一.happens-before的简介

由于存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？

我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before。

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

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

happens-before与JMM的关系如下图所示。

二.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

上面计算圆的面积的示例代码存在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允许这种重排序）。

下图是JMM的设计示意图：

从上图中可以看到：

• JMM向程序员提供的happens-before规则能满足程序员的需求。JMM的happens-before规则不但简单易懂，而且也向程序员提供了足够强的内存可见性保证（有些内存可见性保证其实并不一定真实存在，比如上面的A happens-before B）。
• JMM对编译器和处理器的束缚已经尽可能少。从上面的分析可以看出，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。例如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再如，如果编译器经过细致的分析后，认定一个volatile变量只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

三.happens-before规则

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

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

这里的规则1）、2）、3）和4）前面都讲到过，这里再做个总结。由于2）和3）情况类似，这里
只以1）、3）和4）为例来说明。

3.1volatile变量规则

下图是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的编译器重排序规则共同来保证的。

3.2 start()规则

下面我们来看start()规则。假设线程A在执行的过程中，通过执行ThreadB.start()来启动线程B；同时，假设线程A在执行ThreadB.start()之前修改了一些共享变量，线程B在开始执行后会读这些共享变量。下图是该程序对应的happens-before关系图。

上图中，

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

3.3 join()规则

下面我们来看join()规则。假设线程A在执行的过程中，通过执行ThreadB.join()来等待线
程B终止；同时，假设线程B在终止之前修改了一些共享变量，线程A从ThreadB.join()返回后会
读这些共享变量。图3-36是该程序对应的happens-before关系图。

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

申明:
本篇博文整理自《java并发编程艺术》,仅供大家学习交流,若有侵权,请联系删除。

返回专栏目录