前言
在程序执行时，为了提高性能，编译器和处理器会对指令进行重排序。
为了明确定义多线程场景下重排序的问题（可见性、有序性、原子性），Java引入了JMM(Java Memory Model)，也就是Java内存模型。JMM为JAVA程序员提供了8条规则，即happen-before原则。根据happen-before原则，就可以在不理解复杂的重排序规则情况下，解决因重排序而导致的多线程间可见性、有序性等问题。
happen-before原则
两个操作具有happen-before关系，并不意味着前一个操作比后一个操作先执行！happen-before仅要求前一个操作的执行结果对后一个操作可见。
可以将happen-before原则分两部分理解，单线程与多线程环境下的happen-before。单线程下通过语义分析数据依赖关系，编译器和处理器可以合理的优化我们的代码。但是多线程情况下不同线程间的数据依赖关系有我们定义，处理器与编译器都无法通过分析感知。
happen-before原则定义了某些特定场景下多线程间的数据依赖关系。即happen-before原则是对单线程环境下的指令重排序以及多线程环境下的线程间数据的一致性进行的约束。
对八条原则的理解来自：牛有肉：happen-before原则的理解
(1) 单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。
首先是单线程的 happen-before ，前面的操作产生的结果必须对后面的操作可见。而不是前面的操作必须先于后面的操作执行，比如按照 as-if-serial 语义，没有数据依赖的两条指令是可以进行重排序的。而这种情况对于 happen-before 原则来说，因为两条指令都没有产生对方需要的结果，而不需要对对方可见，及时执行顺序被调转也是符合 happen-before 原则的。
(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操作。
happen-before 可以说是两项操作之间的偏序关系，满足偏序关系的各项性质，我们都知道偏序关系中有一条很重要的性质：传递性，所以happen-before也满足传递性。这个性质非常重要，通过这个性质可以推导出两个没有直接联系的操作之间存在happen-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方法调用。
单线程下对象的创建于销毁存在数据依赖，该条原则强调的是多线程情况下对象初始化的结果必须对发生于其后的对象销毁方法可见。
)
)
