h-a-p-p-e-n-before原则的理解

　happen-before 可真是一个经典又老生常谈的话题，规则一共就八条，但看起来总有种抓不住重点的感觉。今天再整理一下对这八条规则的理解。

　　首先我的理解是 happen-before 的语义与在什么什么之前发生完全没有关系，其语义是如果 A hapen-bfore B，那么 A 的结果对 B 是可见的。通过这些规则可以保证程序按我们预想的方式运转。

         我个人理解中将该原则分两部分理解，单线程与多线程环境下的HB。单线程下通过语义分析数据依赖关系，编译器和处理器可以合理的优化我们的代码。但是多线程情况下不同线程间的数据依赖关系有我们定义，处理器与编译器都无法通过分析感知，HB 原则定义了某些特定场景下多线程间的数据依赖关系。

　　总的来说，HB 原则是对单线程环境下的指令重排序以及多线程环境下的线程间数据的一致性进行的约束。单线程情况下保证串行语义，多线程情况下因为数据的一致性需要我们自己声明和保证，所以 JVM 自行保证了 HB 原则中提出的它认为必须要保证一致性的情况。

　　1. 单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。

　　首先是单线程的 HB ，前面的操作产生的结果必须对后面的操作可见。而不是前面的操作必须先于后面的操作执行，比如按照 as-if-serial 语义，没有数据依赖的两条指令是可以进行重排序的。而这种情况对于 HB 原则来说，因为两条指令都没有产生对方需要的结果，而不需要对对方可见，及时执行顺序被调转也是符合 HB 原则的。

　　2. 锁的happen-before原则：同一个锁的unlock操作happen-before此锁的lock操作。

　　个人理解强调的是解锁操作在多线程环境的可见性。一个线程进行了解锁操作，对于晚于该操作的加锁操作必须能够及时感应到锁的状态变化。解锁操作的结果对后面的加锁操作一定是可见的，无论两个是否在一个线程。

　　3. volatile的happen-before原则：  对一个volatile变量的写操作happen-before对此变量的任意操作。

　　对 volatile 变量的写操作的结果对于发生于其后的任何操作的结果都是可见的。x86 架构下volatile 通过内存屏障和缓存一致性协议实现了变量在多核心之间的一致性。

　　4. happen-before的传递性原则：   如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。

　　HB 可以说是两项操作之间的偏序关系，满足偏序关系的各项性质，我们都知道偏序关系中有一条很重要的性质：传递性，所以Happens-Before也满足传递性。这个性质非常重要，通过这个性质可以推导出两个没有直接联系的操作之间存在Happens-Before关系

　　5. 线程启动的happen-before原则：同一个线程的start方法happen-before此线程的其它方法。

　　start 放法与其它方法可能并没有数据依赖关系，但是显而易见的，为了程序的正确性，我们必须做到这一点。start 方法造成的函数副作用必须对其它方法可见。

　　6. 线程中断的happen-before原则：对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。

　　interrupt 方法改变的状态必须对后续执行的检测方法可见。

　　7. 线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。

　　为了安全的关闭线程，线程中的方法造成的函数副作用必须对线程关闭方法可见。

　　8. 对象创建的happen-before原则：一个对象的初始化完成先于他的finalize方法调用。

　　单线程下对象的创建于销毁存在数据依赖，该条原则强调的是多线程情况下对象初始化的结果必须对发生于其后的对象销毁方法可见。

当你看清人们的真相，于是你知道了，你可以忍受孤独

happen-before是JMM最核心的概念，所以在了解happen-before原则之前，首先需要了解java的内存模型。

JMM内存模型
     java内存模型是共享内存的并发模型，线程之间主要通过读-写共享变量来完成隐式通信。java中的共享变量是存储在内存中的，多个线程由其工作内存，其工作方式是将共享内存中的变量拿出来放在工作内存，操作完成后，再将最新的变量放回共享变量，这时其他的线程就可以获取到最新的共享变量。

     从横向去看看，线程A和线程B就好像通过共享变量在进行隐式通信。这其中有很有意思的问题，如果线程A更新后数据并没有及时写回到主存，而此时线程B读到的是过期的数据，这就出现了 “脏读” 现象。
     为避免脏读，可以通过同步机制（控制不同线程间操作发生的相对顺序）来解决或者通过volatile关键字使得每次volatile变量都能够强制刷新到主存，从而对每个线程都是可见的。

重排序
在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排序。一般重排序可以分为如下三种：如图，1属于编译器重排序，而2和3统称为处理器重排序。
这些重排序会导致线程安全的问题，一个很经典的例子就是DCL问题。JMM的编译器重排序规则会禁止一些特定类型的编译器重排序；针对处理器重排序，编译器在生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。

（1）编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序；
（2）指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序；
（3）内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。

举个例子：

由于A,B之间没有任何关系，对最终结果也不会存在关系，它们之间执行顺序可以重排序。因此可以执行顺序可以是A->B->C或者B->A->C执行最终结果都是3.14，即A和B之间没有数据依赖性。

什么是happen-before
      JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证（如果A线程的写操作a与B线程的读操作b之间存在happens-before关系，尽管a操作和b操作在不同的线程中执行，但JMM向程序员保证a操作将对b操作可见）。

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

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

具体的规则：
(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()操作成功返回。
(7)程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。
(8)对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。

利用程序顺序规则（规则1）存在三个happens-before关系：

A happens-before B；
B happens-before C;
A happens-before C。
这里的第三个关系是利用传递性进行推论的。这里的第三个关系是利用传递性进行推论的。

A happens-before B,定义1要求A执行结果对B可见，并且A操作的执行顺序在B操作之前，但与此同时利用定义中的第二条，A,B操作彼此不存在数据依赖性，两个操作的执行顺序对最终结果都不会产生影响，在不改变最终结果的前提下，允许A，B两个操作重排序，即happens-before关系并不代表了最终的执行顺序。