上一期我们讲到在可见性、原子性、有序性导致的问题是bug的根源。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变量的读操作可见，这怎么看都是禁用缓存的意思。如果但看这个规则的确是，但是关联如下规则就不一样。

3、传递性

这条规则是指如果A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C。

我们将规则3的传递应用到我们的例子中，会发生什么呢？可以看下面这幅图：

从图中，我们可以看到：

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、管程中锁的规则

这条规则是指，一个锁的解锁，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能够看到主线程在启动子线程前的操作。换句话说，如果线程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 事件的发生。

Java内存模型主要分为两部分：一部分面向你我这种编写并发程序的开发人员。另一部分是面向JVM的实现人员的。我们可以重点关注前者，也就是跟并发编程相关的，这部分的核心就是Happens-Before 规则。