02|02|Java内存模型（看Java如何解决可见性和有序性问题） 02|Java内存模型：看Java如何解决

上一期我们讲到在并发场景中可见性、原子性、有序性导致的问题常常会违背我们的直觉，从而成为并发的ＢＵＧ之源。这三者在编程领域属于共性问题，所有的编程语言都会用到，Java 在诞生之初就支持多线程，自然也有针对这三者的技术方案，而且在编程语言领域处于领先地位。理解Java 解决并发问题的解决方案，对于解决其他语言的解决方案有触类旁通的效果。
今天　我们来看下解决可见性、有序性导致的问题，也就是今天的主角：－－Java 内存模型
Java 内存模型这个概念，在职场很多面试中都会考核到，是一个热门的考点，也是一个人并发水平的具体体现，原因是当并发程序出问题时，需要一行一行的检查代码，这个时候只有掌握了Java 内存模型，才能慧眼如炬的发现问题。
什么是 Java 内存模型？你已经知道，导致可见性的原因是缓存，导致有序性的原因是编译优化，那解决可见性、有序性最直接的办法就是禁用缓存和编译优化，但是这样虽然问题解决了，我们程序的性能就堪忧了。
合理的方案应该是按需禁用缓存及编译优化，那么如何做到“按需禁用”呢？对于并发程序，何时禁用缓存及编译优化只有程序员知道，那所谓“按需禁用”其实就是指按照程序员的要求来禁用。所以，为了解决可见性和有序性问题，只需要提供给程序员按需禁用缓存和编译优化即可。
Java 内存模型是个很复杂的规范，可以从不同视角来解读，站在我们这些程序员的视角，本质上可以理解为：Java 内存模型规范了JVM 如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括，volatile、synchronized 和 final 三个关键字，以及六项 Happens-Before 规则，这也正是本期的重点内容。
使用 volatile 的困惑 volatile 关键字并不是Java 语言的特产，古老的C 语言里也有，它最原始的意义就是禁用CPU 缓存。
例如，我们声明一个volatile 变量，volatile int x = 0，它表达的是：告诉编译器，对这个变量的读写，不能使用CPU 缓存，必须从内存中读取或者写入。这个语义看上去相当明确，但是实际使用时候却带来困惑。
例如下面的代码，假设线程Ａ执行 writer() 方法，按照 volatile 语义，会把变量 “v=true” 写入内存；假设线程 B 执行 reader() 方法，同样按照 volatile 语义，线程 B 会从内存中读取变量 v，如果线程 B 看到 “v == true” 时，那么线程 B 看到的变量 x 是多少呢？

// 以下代码来源于【参考1】 class VolatileExample { int x = 0; volatile boolean v = false; public void writer() { x = 42; v = true; } public void reader() { if (v == true) { // 这里x会是多少呢？ } } }

分析一下，为什么 1.5 以前的版本会出现 x = 0 的情况呢？我相信你一定想到了，变量 x 可能被 CPU 缓存而导致可见性问题。这个问题在 1.5 版本已经被圆满解决了。Java 内存模型在 1.5 版本对 volatile 语义进行了增强。怎么增强的呢？答案是一项 Happens-Before 规则。
Happens-Before 规则如何理解Happens-Before 规则？Happens-Before 并不是说前面一个操作发生在后续操作的前面，它真正要表达的是：前面一个操作的结果对后续的操作是可见的。就像心灵感应的两个人，虽然远隔千里，一个人心之所想，另一一个人都看得到。Happens-Before 规则就是要保证线程之间的这种“心灵感应”。所以比较正式的说法是：Happens-Before 约束了编译器的优化行为，虽允许编译器优化，但是要求编译器优化后一定遵守Happens-Before 规则。
Happens-Before 规则应该是Java 内存模型里面最晦涩的内容了，和程序相关的规则共有如下六项，都是关于可见性的。
1、程序的顺序性规则这条规则指在一个线程中，按照程序顺序，前面的操作Happens-Before 于后续的任意操作。这还是比较容易理解的，比如刚才那段示例代码，按照程序的顺序，第 6 行代码 “x = 42; ” Happens-Before 于第 7 行代码 “v = true; ”，这就是规则 1 的内容，也比较符合单线程里面的思维：程序前面对某个变量的修改一定是对后续操作可见的。
2、volatile 变量规则这条规则是指对一个volatile 变量的写操作，Happens-Before 于后续对这个volatile 变量的读操作。
这个就有点费解了，对一个volatile 变量的写操作相对于后续对这个 volatile 变量的读操作可见，这怎么看都是禁用缓存的意思啊?貌似和 1.5 版本以前的语义没有变化啊？如果但看这个规则的却是这样，但是我们关联一下规则3，就有不一样的感觉了。
3、传递性这条规则是指如果A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C。
我们将规则3的传递应用到我们的例子中，会发生什么呢？可以看下面这幅图：

文章图片
img 从图中，我们可以看到：
1、“x=42” Happens-Before 写变量 “v=true” ，这是规则 1 的内容；
2、写变量“v=true” Happens-Before 读变量 “v=true”，这是规则 2 的内容。
再跟进这个传递性规则，我们得到的结果是：“x=42” Happens-Before 读变量“v=true”。这意味着什么呢？
如果线程 B 读到了“v=true”，那么线程 A 设置的“x=42”对线程 B 是可见的。也就是说，线程 B 能看到 “x == 42” ，有没有一种恍然大悟的感觉？这就是 1.5 版本对 volatile 语义的增强，这个增强意义重大，1.5 版本的并发工具包（java.util.concurrent）就是靠 volatile 语义来搞定可见性的，这个在后面的内容中会详细介绍。4. 管程中锁的规则
4、管程中锁的规则这条规则是指对一个锁的解锁，Happens-Before 于后续对这个锁的加锁。
要理解这个规则，就首先要了解“管程指的是什么”。管程是一种通用的同步原语，在Java 中指的就是synchronized，synchronized 是 Java 里对管程的实现。
管程中的锁在Java 里是隐式实现的，例如下面的代码，在进入同步块之前，会自动加锁，而在代码块执行完毕会自动释放锁，加锁及释放锁都是比那一起帮我们实现的。

synchronized (this) { //此处自动加锁 // x是共享变量,初始值=10 if (this.x < 12) { this.x = 12; } } //此处自动解锁

所以结合规则4---管程中锁的规则，可以这样理解，假设 x 的初始值是 10，线程A 执行完代码块后x 的值会变为12（执行完自动释放锁），线程B 进入代码块时，能够看到线程A对x的写操作，也就是线程B 能够看到x==12。这个也符合我们直觉的，应该不难理解。
5、线程 start() 规则这是关于线程启动的。它是指主线程A启动子线程B时候，子线程B能够看到主线程在启动子线程前的操作。
换句话说，如果线程A 调用线程 B 的 start() 方法（即在线程 A 中启动线程 B），那么该 start() 操作 Happens-Before 于线程 B 中的任意操作。具体可参考下面示例代码。

Thread B = new Thread(()->{ // 主线程调用B.start()之前 // 所有对共享变量的修改，此处皆可见 // 此例中，var==77 }); // 此处对共享变量var修改 var = 77; // 主线程启动子线程 B.start();

6、线程 join() 规则这条是关于线程等待的，它是指主线程A等待子线程B完成（主线程A 通过调用子线程 B 的 join() 方法实现），当子线程B 完成后（主线程 A 中 join() 方法返回），主线程能够看到子线程的操作。当然所谓的看到指的是对共享变量的操作。
换句话说，如果在线程A 中，调用线程 B 的 join() 并成功返回，那么线程B 中的任意操作，Happens-Before 于该 join() 操作的返回。具体可以参考下面的代码。

Thread B = new Thread(()->{ // 此处对共享变量var修改 var = 66; }); // 例如此处对共享变量修改， // 则这个修改结果对线程B可见 // 主线程启动子线程 B.start(); B.join() // 子线程所有对共享变量的修改 // 在主线程调用B.join()之后皆可见 // 此例中，var==66

被我们忽视的 final 前面我们讲volatile 为的是禁用缓存以及编译优化，我们从另一个方面来看，有没有办法告诉编译器优化的更好一点呢？这个可以有，就是final 关键字。
final 修饰变量时，初衷是告诉编译器：这个变量生而不变，可以可劲的优化。Java 编译器在1.5以前的版本的却优化的很努力，以至于都优化错了。
问题类似于上一期提到的利用双重检查方法创建单例，构造函数的错误重排导致线程可能看到final 变量值的变化。
当然了，在 1.5 以后 Java 内存模型对 final 类型变量的重排进行了约束。现在只要我们提供正确的构造函数没有“逸出”，就不会出问题了。
“逸出” 有点抽象，我们还是举个例子吧，在下面的例子中，在构造函数里面将this赋值给全局变量global.obj，这就是“逸出”，线程通过global.obj 读取 x 是有可能读到 0 的。因此我们一定要避免“逸出”。

// 以下代码来源于【参考1】 final int x; // 错误的构造函数 public FinalFieldExample() { x = 3; y = 4; // 此处就是讲this逸出， global.obj = this; }

总结 Java 的内存模型是并发编程领域的一次重要创新，之后C++、C#、Golang 等高级语言都开始支持内存模型。 Java 内存模型里面，最晦涩的部门就是Happens-Before 规则了，Happens-Before 规则最初是在一篇叫做Time, Clocks, and the Ordering of Events in a Distributed System 的论文中提出来的，在这篇论文中，Happens-Before 的语义是一种因果关系。在现实世界里，如果 A 事件是导致 B 事件的起因，那么 A 事件一定是先于（Happens-Before）B 事件发生的，这个就是 Happens-Before 语义的现实理解。
在Java 语言里面，Happens-Before 的语义本质上是一种可见性， A Happens-Before B 意味着 A 事件对 B 事件来说是可见的，无论 A 事件和 B 事件是否发生在同一个线程里。例如 A 事件发生在线程 1 上，B 事件发生在线程 2 上，Happens-Before 规则保证线程 2 上也能看到 A 事件的发生。
【02|02|Java内存模型（看Java如何解决可见性和有序性问题）】Java 内存模型主要分为两部分，一部分面向你我这种编写并发程序的应用开发人员，另一部分是面向JVM 的实现人员的，我们可以重点关注前者，也就是和编写并发程序相关的部分，这部分内容的核心就是Happens-Before 规则。