happens-before是JMM的核心概念，也是理解volatile关键字的基础，如果想彻底掌握JMM和并发编程，happens-before是关键
- 首先，从JMM的设计意图来讲，在设计JMM的时候，需要考虑两个问题
- 程序员对内存模型的使用，程序员希望内存模型易于理解、易于编程，即：在编写代码的时候，有一个强内存模型
- 编译器和处理器的角度来说，希望内存模型对它的束缚越少越好，这样就可以尽可能的对性能进行优化，即： 编译器和处理希望实现一个弱内存模型
- 基于以上两点，在设计JMM的时候，找到了一个好的平衡点，一方面要为程序员提供足够的内存可见性保障，另一方面，对编译器和处理器的限制要尽量的宽松
如下案例
double pi = 3.14; //A
double r = 1; //B
double area = pi * r * r; //C
- 以上代码中存在3个happens-before关系
- A happens-before B
- B happens-before C
- A happens-before C
- 其中，2和3是必须的，但是1不是必须的，1和2的执行顺序并不会影响执行的结果，因此JMM把happens-before要求禁止的重排序分为了一下两类
- 会改变程序的执行结果的重排序
- 不会改变程序执行结果的重排序
- 因此，JMM对于不同性质的重排序，采取了不同的策略，如：
- 对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序
- 对于不会改变程序执行结果的重排序，JMM对编译器和处理不做要求(其实JMM允许这种重排序)
- JMM对编译器和处理器的约束已经尽可能的少，其基本原则是，只要不改变程序的执行结果(单线程程序和正确同步的多线程程序)，编译器和处理器可以随意优化，如，如果编译器经过细致的分析后，认定一个锁只会被单线程程序访问，那么这个锁可以被消除，再如，如果编译器经过细致的分析后，认定一个volatile类型的变量，只会被单个的线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待，这些优化都不会改变程序的执行结果，却又可以提高程序的执行效率
happens-before的定义
- 如果一个操作happens-before另一个操作，那么第一个操作的执行结果会对第二个操作可见，而且第一个操作的执行顺序会排在第二个操作之前
- 两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行，如果重排序之后的结果，与按happens-before关系执行的结果一致，那么这种重排序并不非法(也就是说，JMM允许这种重排序)
- 其实对于2中，程序员对于两个操作是否重排序并不关心，我们关心的是执行的结果不能被更改，因此，happens-before的本质和as-if-serial语义基本就是一回事。
as-if-serial
- as-if-serial语义保证单线程程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变
- as-if-serial语义给编写单线程程序创造一个幻境，单线程程序是按照程序的顺序来执行的。happens-before关系给编写正确的多线程程序员创造了一个幻境，正确同步的多线程程序是按照happens-before指定的顺序来执行的
- as-if-serial和happens-before这么做的目的，就是为了在不改变程序执行结果的前提下，尽可能的提高程序执行的并行度
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-beofre于线程A从ThreadB.join()操作成功返回
参考：
周志明：《深入理解Java虚拟机》
方腾飞：《Java并发编程的艺术》
写在最后
我的灵魂离我如此遥远，而我的存在却如此的真实
