【搞定Java并发编程】第12篇：happens-before

分手后的思念是犯贱 2022-04-06 15:40 422阅读 0赞

** 上一篇：final域的内存语义：[https://blog.csdn.net/pcwl1206/article/details/84925372][https_blog.csdn.net_pcwl1206_article_details_84925372]**

## **目  录：** ##

**1、JMM的设计**

**2、happens-before的定义**

**3、happens-before规则**

--------------------

其实我们在前面的**[Java内存模型][Java]**中已经讲过happens-before。但是因为happens-before是JMM最核心的概念。所以这里再做下详细的讲解。本文内容主要来自于《Java并发编程的艺术》一书，算是把自己的读书笔记记录在此。

# 1、JMM的设计 #

JMM设计时一方面要为程序员提供足够强的内存可见性保证；另一方面对编译器和处理器的限制要尽可能的放松，设计JMM时需要进行平衡。

【案例1】

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要求禁止的重排序分为了下面两类：

> **1、会改变程序执行结果的重排序；**
> 
> **2、不会改变程序执行结果的重排序。**

JMM的设计示意图如下所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70][]**JMM的设计示意图**

从上图可以看出两点：

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

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

--------------------

# 2、happens-before的定义 #

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

**happens-before定义：**

> 1、如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前；
> 
> 2、两个操作之间存在 happens-before关系，并不意味着Java平台的具体实现必须要按照 happens-before关系指定的顺序执行。只要重排序的执行结果与按照 happens-before执行的结果一致，那么JMM允许这种重排序。

第一点是JMM对程序员的承诺，第二点是JMM对编译器和处理器重排序的约束原则。

--------------------

# 3、happens-before规则 #

> **1、程序顺序原则**：即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行；
> 
> **2、锁规则：**解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前。也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)；
> 
> **3、volatile规则：**volatile变量的“写”先发生于“读”，这保证了volatile变量的可见性。简单的理解就是：volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值；而当该变量值发生变化时，又会强迫将最新的值刷新到主内存中。因此，任何时刻，不同的线程总是能够看到该变量的最新值；
> 
> **4、线程启动规则**：线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B是可见的；
> 
> **5、传递性**：A先于B ，B先于C ，那么A必然先于C；
> 
> **6、线程终止规则：**线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。
> 
> **7、线程中断规则：**对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。
> 
> **8、对象终结规则：**对象的构造函数执行（对象的初始化），结束先于finalize()方法；

这里从中挑几种讲解下：

*  ### volatile规则 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 1][]**happens-before关系的示意图**

*  1 happens-before 2 和 3 happens-before 4由程序的顺序规则产生；
 *  2 happens-before 3 是由volatile规则产生；
 *  1 happens-before 4 是由传递性规则产生的。

--------------------

*  ### 线程启动规则 ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 2][]

*  1  happens-before  2 由程序顺序规则产生；
 *  2  happens-before  4 由start()规则产生；
 *  1  happens-before  4 由传递性产生。

这就意味着，线程A在执行ThreadB.start()之前对共享变量所做的修改，接下来在线程B开始执行后都将确保对线程B可见。

--------------------

*  ### 线程终止规则 / join()  ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 3][]

*  2  happens-before  4：join()规则产生；
 *  4  happens-before  5：程序顺序规则产生；
 *  2  happens-before  5：传递性规则产生。

这也就意味着，线程A执行操作ThreadB.join()并成功返回后，线程B中的任意操纵都将对线程A可见。

--------------------

** 上一篇：final域的内存语义：[https://blog.csdn.net/pcwl1206/article/details/84925372][https_blog.csdn.net_pcwl1206_article_details_84925372]**

[https_blog.csdn.net_pcwl1206_article_details_84925372]: https://blog.csdn.net/pcwl1206/article/details/84925372
[Java]: https://blog.csdn.net/pcwl1206/article/details/84871090#5.2%E3%80%81%E6%8C%87%E4%BB%A4%E9%87%8D%E6%8E%92
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70]: /images/20220406/a3fd810602324c93b18375b0eef4d3f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 1]: /images/20220406/3bf0cd8ddeff44bab6e4663e02db5ba8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 2]: /images/20220406/ce59737fbeb44dbaae4f6a6581278a5c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bjd2wxMjA2_size_16_color_FFFFFF_t_70 3]: /images/20220406/fbd3f746a59a41d28345092d92152387.png