happens-before规则

happens-before是操作间的一种关系，happens-before规则规定，若操作A happens-before于操作B，则A的操作结果对于B是可见的（可见性），且A的逻辑执行顺序也一定在B前面（有序性）

注意：A的逻辑执行顺序在B前面，但是实际上从物理执行顺序来讲，A的执行顺序不一定在B前面。

 

我们从程序员和cpu/编译器的角度来看看happens-before到底有什么用

 

程序员角度看happens-before

作为程序员，我们往往需要我们所编写的代码的执行结果能按照我们预想的一样，在早期不涉及多线程问题（单线程）的情况下，我们所编写的代码足以保证我们程序的执行结果能按照我们预期一样，且cpu/编译器重排序的核心前提条件就是优化前后的程序执行结果对于单线程来说是一致的。因此早期我们并不需要过多关注程序在多线程环境下执行是否会发生问题

 

后续随着技术的进步，产生了多线程的环境，而随着cpu/编译器指令重排序，cpu缓存等计划的退出，我们的程序在多线程的情况下，其执行结果可能无法使我们程序员满意，那这种时候该怎么办呢，作为程序员，肯定是希望能有一种机制，在简单使用的同时，还能帮助我们程序员编写出一个不会出问题的多线程程序。

 

于是happens-before规则出现了，前面说过，这是一种操作间关系，简单理解就是，只要我们程序员能在多线程环境下建立一些操作之间的happens-before关系（采用锁等同步技术），我们就能确保这些操作的执行结果可预测。

 

所以从程序员角度来看，happens-before规则能让我们更简单的编写出优秀的并发程序而存在的，我们程序员只要想办法让两个操作间存在happens-before就行了

 

补充：在单线程程序当中存在天然的happens-before关系，因为单线程程序的执行结果就是按照我们预想的结果一样

 

从cpu/编译器角度看happens-before

其实如果想要解决多线程环境下的问题，其实最治“本”的方法就是，直接禁止指令重排序和内存缓存，但是这样明显会“过重”导致效率低下，往往cpu/编译器希望能竭尽所能的去优化，最好是没有任何阻碍让cpu/编译器尽情优化。

 

但是不论是不优化还好还是尽情优化也好，显然都太极端了，我们能否采用一种折中方案呢，即我让cpu/编译器尽可能的去优化，但是设定一些规则，只要不超出这个规则，cpu/编译器就可以尽情优化了。

 

这个时候happens-before站出来了，cpu/编译器优化重排序的是操作，而hanppens-before描述的也是操作间的关系，那结合出来，我们就有

 

对于有happens-before关系的操作之间，我们不能让cpu/before对其随意重排序，而是要根据规则来考虑是否能重排序具有happens-before关系的操作，而没有这种关系的操作，cpu/编译器随意优化重排序即可。

 

happens-before规则

• 程序顺序规则（Program Order Rule）
  在同一个线程中，按照程序代码顺序，前面的操作 happens-before 后面的操作。
• 监视器锁规则（Monitor Lock Rule）
  对一个监视器锁（synchronized）的解锁（unlock）happens-before 后续对该锁的加锁（lock）。
• volatile 变量规则（Volatile Variable Rule）
  对一个 volatile 变量的写操作 happens-before 后续对该变量的读操作。
• 线程启动规则（Thread Start Rule）
  线程 A 中调用 threadB.start() 的操作 happens-before 线程 B 中的任意操作。
• 线程 join 规则（Thread Join Rule）
  线程 B 中的所有操作 happens-before 线程 A 中对 threadB.join() 成功返回的点。
• 中断规则（Interrupt Rule）
  对线程调用 interrupt() 的操作 happens-before 被中断线程检测到中断（如抛出 InterruptedException 或 isInterrupted() 返回 true）。
• 传递性规则（Transitivity）
  如果 A happens-before B，且 B happens-before C，则 A happens-before C。
• 对象终结规则（Finalizer Rule）
  对象的构造函数执行结束 happens-before 它的 finalize() 方法开始。（注：finalize() 已在 Java 9+ 被弃用）