Android工程师进阶第四课 jmm内存模型和juc多线程基础

第07讲：Java 内存模型与线程

本课时我们将进入 Java 内存模型的学习。

Java 内存模型一词翻译自 Java Memory Model，简称 JMM，它所描述的是多线程并发、CPU 缓存等方面的内容，这里需要注意不要将它与课时 01 讲到的 JVM 内存结构混淆。

为什么有 Java 内存模型

网上大多数文章在介绍 JMM 时，都会引用《深入理解 Java 虚拟机》中的一张图，如下：

上图描述的意思是，在每一个线程中，都会有一块内部的工作内存（working memory）。这块工作内存保存了主内存共享数据的拷贝副本。在第 1 课时中，我们了解到在 JVM 内存结构中有一块线程独享的内存空间——虚拟机栈，所以这里我们会自然而然的将线程工作内存理解为虚拟机栈。

实际上，这种理解是不准确的！虚拟机栈和线程的工作内存并不是一个概念。在 Java 线程中并不存在所谓的工作内存（working memory），它只是对 CPU 寄存器和高速缓存的抽象描述。

CPU 普及

你可能会感到奇怪，怎么突然又扯到 CPU 了？作为一个程序员，尤其是 Java 程序员，我们都应该知道线程是 CPU 调度的最小单位，线程中的字节码指令最终都是在 CPU 中执行的。CPU在执行的时候，免不了要和各种数据打交道，而 Java 中所有数据都是存放在主内存（RAM）当中的，这一过程可以参考下图：

随着 CPU 技术的发展，CPU 的执行速度越来越快，但内存的技术并没有太大的变化，所以在内存中读取和写入数据的过程和 CPU 的执行速度比起来差距会越来越大，也就是上图中箭头部分。CPU 对主内存的访问需要等待较长的时间，这样就体现不出 CPU 超强运算能力的优势了。

因此，为了“压榨”处理性能，达到“高并发”的效果，在 CPU 中添加了高速缓存（cache）来作为缓冲。

在执行任务时，CPU 会先将运算所需要使用到的数据复制到高速缓存中，让运算能够快速进行，当运算完成之后，再将缓存中的结果刷回（flush back）主内存，这样 CPU 就不用等待主内存的读写操作了。

一切看起来很美好，但是问题也随之而来。每个处理器都有自己的高速缓存，同时又共同操作同一块主内存，当多个处理器同时操作主内存时，可能导致数据不一致，这就是是缓存一致性问题。

缓存一致性问题

现在市面上的手机通常有两个或者多个 CPU，其中一些 CPU 还有多核。每个 CPU 在某一时刻都能运行一个线程，这就意味着，如果你的 Java 程序是多线程的，那么就有可能存在多个线程在同一时刻被不同的CPU执行的情况。

比如我们有如下一段代码：

这里我定义了两个变量 x 和 y ，它们的初始值都为 0。

在线程 p1 中，将 x 赋值给局部变量 r1，然后将 y 重新设为 1 。

在线程 p2 中，将 y 赋值给局部变量 r2，然后将 x 重新设为 2。

假设我们的一台设备上有 2 个 CPU，分别为 C1 和 C2，我们将上面这段代码执行在这台设备上，最后打印出的 r1 和 r2 值分别是多少？答案是不确定的。

r1 = 0，r2 = 1

假设 p1 先在 C1 中执行完毕，并成功刷新回主内存中，此时 r1 = 0, x = 0, y = 1。

然后 p2 在 C2 中执行，从主内存中加载 y = 1 并赋值给 r2，此时 r2 = 1, x = 2, y = 1

r1 = 2，r2 = 0

假设 p2 先在 C1 中执行完毕，并成功刷新回主内存中，此时 r2 = 0, x = 2, y = 0。

然后 p1 在 C2 中执行，从主内存中加载 y = 1 并赋值给 r2，此时 r1 = 2, x = 2, y = 1。

上述两种情况比较明显，当某些情况下还会出现另一种情况

r1 = 0，r2 = 0

x 和 y 的值分别缓存在 C1 和 C2 的缓存中。

首先 p1 在 C1 中执行完毕，但是并未将结果刷新回主内存中，此时主内存中的 x = 0，y = 0。

然后 p2 在 C2 中执行，缓存中的 y = 0，将其赋值给 r2，此时 r2 = 0, x = 2, y = 1

如下图所示：

可以看出，虽然在 C1 和 C2 的缓存中，分别修改了 x 和 y 的值，但是并未将它们刷新回主内存中，这就是缓存一致性问题。

指令重排

除了缓存一致性问题，还存在另外一种硬件问题，也比较重要：为了使 CPU 内部的运算单元能够尽量被充分利用，处理器可能会对输入的字节码指令进行重排序处理，也就是处理器优化。除了 CPU 之外，很多编程语言的编译器也会有类似的优化，比如 Java虚拟机的即时编译器（JIT）也会做指令重排。

以下面的代码为例：

编译之后的字节码指令如下：

可以看出在上述指令中，有两处指令表达的是同样的语义，并且指令 7 并不依赖指令 2 和指令 3。在这种情况下，CPU 会对指令的顺序做优化，如下：

从 Java 语言的角度看这层优化就是：

也就是说在 CPU 层面，有时候代码并不会严格按照 Java 文件中的顺序去执行。再看一下之前 r1/r2 的实例，刚才我们分析会有 3 种情况发生，其实在极端情况下，还会出现第 4 种情况：

r1 = 2，r2 = 1

线程 p2 中的代码经过 CPU 优化之后，会被重排序为：

经过优化之后，p2 线程将 x 赋值为 2，这时 CPU 将时间片段分配给线程 p1，线程 p1 在执行过程中，将 r1 赋值为 x，此时 x = 2，所以 r1 的值为 2。然后将 y 赋值为 1，此时 CPU 再将时间片段重新分配给 p2。

代码回到 p2 中，将 y 值赋值给 r2，此时 y = 1，所以 r2 = 1，整个过程如下图所示：

图中红色图标代表代码执行的顺序。

上面两小部分内容表明，如果我们任由 CPU 优化或者编译器指令重排，那我们编写的 Java 代码最终执行效果可能会极大的出乎意料。为了解决这个问题，让 Java 代码在不同硬件、不同操作系统中，输出的结果达到一致，Java 虚拟机规范提出了一套机制——Java 内存模型。

什么是内存模型

内存模型是一套共享内存系统中多线程读写操作行为的规范，这套规范屏蔽了底层各种硬件和操作系统的内存访问差异，解决了 CPU 多级缓存、CPU 优化、指令重排等导致的内存访问问题，从而保证 Java 程序（尤其是多线程程序）在各种平台下对内存的访问效果一致。

在 Java 内存模型中，我们统一用工作内存（working memory）来当作 CPU 中寄存器或高速缓存的抽象。线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有工作内存（类比 CPU 中的寄存器或者高速缓存），本地工作内存中存储了该线程读/写共享变量的副本。

在这套规范中，有一个非常重要的规则——happens-before。

happens-before 先行发生原则

happens-before 用于描述两个操作的内存可见性，通过保证可见性的机制可以让应用程序免于数据竞争干扰。它的定义如下：

如果一个操作 A happens-before 另一个操作 B，那么操作 A 的执行结果将对操作 B 可见。

上述定义我们也可以反过来理解：如果操作 A 的结果需要对另外一个操作 B 可见，那么操作 A 必须 happens-before 操作 B。

用以下代码来举例：

假设 setValue 就是操作 A，getValue 就是操作 B。如果我们先后在两个线程中调用 A 和 B，那最后在 B 操作中返回的 value 值是多少呢？有以下两种情况：

如果 A happens-before B 不成立

也就是说当线程调用操作 B（getValue）时，即使操作 A（setValue）已经在其他线程中被调用过，并且 value 也被成功设置为 1，但这个修改对于操作 B（getValue）仍然是不可见的。根据之前我们介绍的 CPU 缓存，value 值有可能返回 0，也有可能返回 1。

如果 A happens-before B 成立

根据 happens-before 的定义，先行发生动作的结果，对后续发生动作是可见的。也就是说如果我们先在一个线程中调用了操作 A（setValue）方法，那么这个修改后的结果对后续的操作 B（getValue）始终可见。因此如果先调用 setValue 将 value 赋值为 1 后，后续在其他线程中调用 getValue 的值一定是 1。

那在 Java 中的两个操作如何就算符合 happens-before 规则了呢？ JMM 中定义了以下几种情况是自动符合 happens-before 规则的：

程序次序规则

在单线程内部，如果一段代码的字节码顺序也隐式符合 happens-before 原则，那么逻辑顺序靠前的字节码执行结果一定是对后续逻辑字节码可见，只是后续逻辑中不一定用到而已。比如以下代码：

int a = 10;  // 1
b = b + 1;   // 2

当代码执行到 2 处时，a = 10 这个结果已经是公之于众的，至于用没用到 a 这个结果则不一定。比如上面代码就没有用到 a = 10 的结果，说明 b 对 a 的结果没有依赖，这样就有可能发生指令重排。

但是如果将代码改为如下则不会发生指令重排优化：

int a = 10;  // 1
b = b + a;   // 2

锁定规则

无论是在单线程环境还是多线程环境，一个锁如果处于被锁定状态，那么必须先执行 unlock 操作后才能进行 lock 操作。

变量规则

volatile 保证了线程可见性。通俗讲就是如果一个线程先写了一个 volatile 变量，然后另外一个线程去读这个变量，那么这个写操作一定是 happens-before 读操作的。

线程启动规则

Thread 对象的 start() 方法先行发生于此线程的每一个动作。假定线程 A 在执行过程中，通过执行 ThreadB.start() 来启动线程 B，那么线程 A 对共享变量的修改在线程 B 开始执行后确保对线程 B 可见。

线程中断规则

对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测，直到中断事件的发生。

线程终结规则

线程中所有的操作都发生在线程的终止检测之前，我们可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值等方法检测线程是否终止执行。假定线程 A 在执行的过程中，通过调用 ThreadB.join() 等待线程 B 终止，那么线程 B 在终止之前对共享变量的修改在线程 A 等待返回后可见。

对象终结规则

一个对象的初始化完成发生在它的 finalize() 方法开始前。

此外， happens-before 原则还具有传递性：如果操作 A happens-before 操作 B，而操作 B happens-before 操作 C，则操作 A 一定 happens-before 操作 C。

Java 内存模型应用

上面介绍的 happens-before 原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，根据这个原则，我们能够解决在并发环境下操作之间是否可能存在冲突的所有问题。在此基础上，我们可以通过 Java 提供的一系列关键字，将我们自己实现的多线程操作“happens-before 化”。

"happens-before 化”就是将本来不符合 happens-before 原则的某些操作，通过某种手段使它们符合 happens-before 原则。

比如我还是用上面的 setValue 和 getValue 举例，本来这两个操作是不符合 happens-before 原则的，但是我们可以通过以下两种方式，使它们符合 happens-before 原则。

使用 volatile 修饰 value

使用synchronized关键字修饰操作

通过以上两种方式，都可以使 setValue 和 getValue 符合 happens-before 原则——当在某一线程中调用 setValue 后，再在其他线程中调用 getValue 获取的值一定是 1。

总结

本课时我们主要介绍了以下几点：

Java 内存模型的来源：主要是因为 CPU 缓存和指令重排等优化会造成多线程程序结果不可控。
Java 内存模型是什么：本质上它就是一套规范，在这套规范中有一条最重要的 happens-before 原则。
最后介绍了 Java 内存模型的使用，其中简单介绍了两种方式：volatile 和 synchronized。其实除了这两种方式，Java 还提供了很多关键字来实现 happens-before 原则，后续课时中将会详细介绍。

第08讲：既生 Synchronized，何生 ReentrantLock

synchronized 关键字相信每一位 Java 工程师都不会陌生。而 ReentrantLock 作为大神 Doug Lea 编写的 concurrent 包中的重要一员，也在众多项目中发挥重要功能。因为这两者实在是太重要，所以专门使用一课时的内容来对它们做一个详细的比较。后续两课时将会着重介绍它们各自的实现细节与原理。

synchronized

synchronized 可以用来修饰以下 3 个层面：

修饰实例方法；
修饰静态类方法；
修饰代码块。

synchronized 修饰实例方法

这种情况下的锁对象是当前实例对象，因此只有同一个实例对象调用此方法才会产生互斥效果，不同实例对象之间不会有互斥效果。比如如下代码：

上述代码，在不同的线程中调用的是不同对象的 printLog 方法，因此彼此之间不会有排斥。运行效果如下：

可以看出，两个线程是交互执行的。

如果将代码进行如下修改，两个线程调用同一个对象的 printLog 方法：

则执行效果如下：

可以看出：只有某一个线程中的代码执行完之后，才会调用另一个线程中的代码。也就是说此时两个线程间是互斥的。

修饰静态类方法

如果 synchronized 修饰的是静态方法，则锁对象是当前类的 Class 对象。因此即使在不同线程中调用不同实例对象，也会有互斥效果。

将 LagouSynchronizedMehtods 中的 printLog 修改为静态方法，如下：

执行后的打印效果如下：

可以看出，两个线程还是依次执行的。

synchronized 修饰代码块

除了直接修饰方法之外，synchronized 还可以作用于代码块，如下代码所示：

synchronized 作用于代码块时，锁对象就是跟在后面括号中的对象。上图中可以看出任何 Object 对象都可以当作锁对象。

实现细节

synchronized 既可以作用于方法，也可以作用于某一代码块。但在实现上是有区别的。比如如下代码，使用 synchronized 作用于代码块：

使用 javap 查看上述 test1 方法的字节码，可以看出，编译而成的字节码中会包含 monitorenter 和 monitorexit 这两个字节码指令。如下所示：

你可能已经发现了，上面字节码中有 1 个 monitorenter 和 2 个 monitorexit。这是因为虚拟机需要保证当异常发生时也能释放锁。因此 2 个 monitorexit 一个是代码正常执行结束后释放锁，一个是在代码执行异常时释放锁。

再看下 synchronized 修饰方法有哪些区别：

从图中可以看出，被 synchronized 修饰的方法在被编译为字节码后，在方法的 flags 属性中会被标记为 ACC_SYNCHRONIZED 标志。当虚拟机访问一个被标记为 ACC_SYNCHRONIZED 的方法时，会自动在方法的开始和结束（或异常）位置添加 monitorenter 和 monitorexit 指令。

关于 monitorenter 和 monitorexit，可以理解为一把具体的锁。在这个锁中保存着两个比较重要的属性：计数器和指针。

计数器代表当前线程一共访问了几次这把锁；
指针指向持有这把锁的线程。

用一张图表示如下：

锁计数器默认为0，当执行monitorenter指令时，如锁计数器值为0 说明这把锁并没有被其它线程持有。那么这个线程会将计数器加1，并将锁中的指针指向自己。当执行monitorexit指令时，会将计数器减1。

ReentrantLock

ReentrantLock 基本使用

ReentrantLock 的使用同 synchronized 有点不同，它的加锁和解锁操作都需要手动完成，如下所示：

图中 lock() 和 unlock() 分别是加锁和解锁操作。运行效果如下：

可以看出，使用 ReentrantLock 也能实现同 synchronized 相同的效果。

你可能已经注意到，在上面 ReentrantLock 的使用中，我将 unlock 操作放在 finally 代码块中。这是因为 ReentrantLock 与 synchronized 不同，当异常发生时 synchronized 会自动释放锁，但是 ReentrantLock 并不会自动释放锁。因此好的方式是将 unlock 操作放在 finally 代码块中，保证任何时候锁都能够被正常释放掉。

公平锁实现

ReentrantLock 有一个带参数的构造器，如下：

默认情况下，synchronized 和 ReentrantLock 都是非公平锁。但是 ReentrantLock 可以通过传入 true 来创建一个公平锁。所谓公平锁就是通过同步队列来实现多个线程按照申请锁的顺序获取锁。

公平锁使用实例如下：

运行效果如下：

可以看出，创建的 3 个线程依次按照顺序去修改 sharedNumber 的值。

网上对公平锁有一段例子很经典：假设有一口水井，有管理员看守，管理员有一把锁，只有拿到锁的人才能够打水，打完水要把锁还给管理员。每个过来打水的人都要得到管理员的允许并拿到锁之后才能去打水，如果前面有人正在打水，那么这个想要打水的人就必须排队。管理员会查看下一个要去打水的人是不是队伍里排最前面的人，如果是的话，才会给你锁让你去打水；如果你不是排第一的人，就必须去队尾排队，这就是公平锁。

读写锁（ReentrantReadWriteLock）

在常见的开发中，我们经常会定义一个线程间共享的用作缓存的数据结构，比如一个较大的 Map。缓存中保存了全部的城市 Id 和城市 name 对应关系。这个大 Map 绝大部分时间提供读服务（根据城市 Id 查询城市名称等）。而写操作占有的时间很少，通常是在服务启动时初始化，然后可以每隔一定时间再刷新缓存的数据。但是写操作开始到结束之间，不能再有其他读操作进来，并且写操作完成之后的更新数据需要对后续的读操作可见。

在没有读写锁支持的时候，如果想要完成上述工作就需要使用 Java 的等待通知机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后，所有等待的读操作才能继续执行。这样做的目的是使读操作能读取到正确的数据，不会出现脏读。

但是如果使用 concurrent 包中的读写锁（ReentrantReadWriteLock）实现上述功能，就只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续的读写锁都会被阻塞，写锁释放之后，所有操作继续执行，这种编程方式相对于使用等待通知机制的实现方式而言，变得简单明了。

接下来，我们看下读写锁（ReentrantReadWriteLock）如何使用：

1. 创建读写锁对象：

2. 通过读写锁对象分别获取读锁（ReadLock）和写锁（WriteLock）：

3. 使用读锁（ReadLock）同步缓存的读操作，使用写锁（WriteLock）同步缓存的写操作：

具体实现，参考如下代码片段：

解释说明：

图中的 number 是线程中共享的数据，用来模拟缓存数据；
图中①处，分别创建 2 个 Reader 线程并从缓存中读取数据，和 1 个 Writer 将数据写入缓存中；
图中②处，使用读锁（ReadLock）将读取数据的操作加锁；
图中③处，使用写锁（WriteLock）将写入数据到缓存中的操作加锁。

上述代码执行效果如下：

仔细查看日志，可以看出当写入操作在执行时，读取数据的操作会被阻塞。当写入操作执行成功后，读取数据的操作继续执行，并且读取的数据也是最新写入后的实时数据。

总结

这课时我们主要学习了 Java 中两个实现同步的方式 synchronized 和 ReentrantLock。其中 synchronized 使用更简单，加锁和释放锁都是由虚拟机自动完成，而 ReentrantLock 需要开发者手动去完成。但是很显然 ReentrantLock 的使用场景更多，公平锁还有读写锁都可以在复杂场景中发挥重要作用。