深刻讲解并发编程模型之概念篇

笔者知识和理解有限，欢迎指出不足之处

并发编程模型的分类

在并发编程中，咱们须要处理两个关键问题

• 线程之间如何通讯

这里的线程是指并发执行的活动实体。通讯是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通讯机制有两种:<span style="color:blue">共享内存、消息传递</span>。

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间经过写-读内存中的公共状态来隐式进行通讯。

在消息传递的并发模型里，线程之间没有公共状态，线程之间必须经过明确的发送消息来显式进行通讯。

• 线程之间如何同步

同步是指程序用于控制不一样线程之间操做发生相对顺序的机制。

在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码须要在线程之间互斥执行。

在消息传递的并发模型里，因为消息的发送必须在消息的接收以前，所以同步是隐式进行的。

<span style="color:blue">Java 的并发采用的是共享内存模型</span>，Java线程之间的通讯老是隐式进行（注意不是说同步是隐式，而是说共享内存在Java中是隐式进行），整个通讯过程对程序员彻底透明。若是编写多线程程序的Java程序员不理解隐式进行的线程之间通讯的工做机制，极可能会遇到各类奇怪的内存可见性问题。

用一张图总结并发编程模型：

Java内存模型的抽象

<span style="color:blue">在java中，全部实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共 享(本文使用“共享变量”这个术语代指实例域，静态域和数组元素)。</span>

局部变量 (Local variables)，方法定义参数(java语言规范称之为formal method parameters)和异常处理器参数(exception handler parameters)不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

Java 线程之间的通讯由 Java 内存模型(本文简称为 JMM)控制，JMM 决定一个 线程对共享变量的写入什么时候对另外一个线程可见。从抽象的角度来看，<span style="color:blue">JMM定义了线程和主内存之间的抽象关系:

<span style="color:red">线程之间的共享变量存储在主内存(main
memory)中</span>，<span style="color:red">每一个线程都有一个私有的本地内存(local memory)</span>，本地内存中存储了该线程以读/写共享变量的副本。本地内存是 JMM 的一个抽象概念，并不 真实存在。它涵盖了缓存，写缓冲区，寄存器以及其余的硬件和编译器优化。</span>

Java 内存模型的抽象示意图以下：

名词解释：

• read（从主存读取）
• load（将主存读取到的值写入工做内存）
• use（从工做内存读取数据来计算）
• assign（将计算好的值从新赋值到工做内存中）
• store（将工做内存数据写入主存）
• write（将store过去的变量值赋值给主存中的变量）

从上图来看，线程 A 与线程 B 之间如要通讯的话，必需要经历下面 2 个步骤:

1. 首先，线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去。
2. 而后，线程 B 到主内存中去读取线程 A 以前已更新过的共享变量。

下面经过示意图来讲明这两个步骤:

如上图所示，本地内存 A 和 B 有主内存中共享变量 m 的副本。

假设初始时，这三个 内存中的 m 值都为 0。线程 A 在执行时，把更新后的 m 值(假设值为 1)临时存放 在本身的本地内存 A 中。当线程 A 和线程 B 须要通讯时，线程 A 首先会把本身本地内存中修改后的 m 值刷新到主内存中，此时主内存中的 m 值变为了 1。随后，线程 B 到主内存中去读取线程 A 更新后的 m 值，此时线程 B 的本地内存的 m 值也变 为了 1。

从总体来看，这两个步骤实质上是线程 A 在向线程 B 发送消息，并且这个通讯过程 必需要通过主内存。JMM 经过控制主内存与每一个线程的本地内存之间的交互，<span style="color:blue">来为 java 程序员提供内存可见性保证。</span>

### 重排序
在执行程序时为了提升性能，编译器和处理器经常会对指令作重排序。重排序分三
种类型:

• 编译器优化的重排序

编译器在不改变单线程程序语义的前提下，能够从新安排语句的执行顺序。

• 指令级并行的重排序

现代处理器采用了指令级并行技术(Instruction-Level Parallelism， ILP)来将多条指令重叠执行。若是不存在数据依赖性，处理器能够改变语句对应机器指令的执行顺序。

• 内存系统的重排序

因为处理器使用缓存和读/写缓冲区，这使得加载和存储操做看上去多是在乱序执行。

从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序:

上述的<span style="color:blue">编译器优化重排序</span>属于编译器重排序，<span style="color:blue">指令级并行重排序</span>和<span style="color:blue">内存系统重排序</span>属于处理器重排序。

这些重排序均可能会致使多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序(不是全部的编译器重排序都要禁止)。

对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类 型的内存屏障(memory barriers，intel 称之为 memory fence)指令，经过内存屏障指令来禁止特定类型的处理器重排序(不是全部的处理器重排序都要禁 止)。

JMM 属于语言级的内存模型，它确保在不一样的编译器和不一样的处理器平台之上，经过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

处理器重排序与内存屏障指令

现代的处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区能够保证指令流水线持续运行，它能够避免因为处理器停顿下来等待向内存写入数据而产生的延 迟。

同时，经过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的屡次写，能够减小对内存总线的占用。

虽然写缓冲区有这么多好处，但每一个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操做的执行顺序产生重要的影响:处理器对内存的读/写操做的执行顺序，不必定与内存实际发生的读/写操做顺序一致!为了具体说明，请看下面示例:

假设处理器 A 和处理器 B 按程序的顺序并行执行内存访问，最终却可能获得 x = y = 0 的结果。具体的缘由以下图所示:

这里处理器 A 和处理器 B 能够同时把共享变量写入本身的写缓冲区(A1，B1)， 而后从内存中读取另外一个共享变量(A2，B2)，最后才把本身写缓存区中保存的 脏数据刷新到内存中(A3，B3)。当以这种时序执行时，程序就能够获得 x = y = 0 的结果。

从内存操做实际发生的顺序来看，直处处理器 A 执行 A3 来刷新本身的写缓存区， 写操做 A1 才算真正执行了。虽然处理器 A 执行内存操做的顺序为:A1->A2，但内存操做实际发生的顺序倒是:A2->A1。此时，处理器 A 的内存操做顺序被重排序了(处理器 B 的状况和处理器 A 同样，这里就不赘述了)。

这里的关键是，因为写缓冲区仅对本身的处理器可见，它会致使处理器执行内存操 做的顺序可能会与内存实际的操做执行顺序不一致。因为现代的处理器都会使用写缓冲区，所以现代的处理器都会容许对写-读操做重排序。

下面是常见处理器容许的重排序类型的列表:

上表单元格中的“N”表示处理器不容许两个操做重排序，“Y”表示容许重排序。

从上表咱们能够看出:

常见的处理器都容许 Store-Load 重排序。

常见的处理器都不容许对存在数据依赖的操做作重排序。

sparc-TSO 和 x86 拥有相对较强的处理器内存模型，它们仅容许对写-读操做作重排序(由于它们都使用了写缓冲区)。

• sparc-TSO 是指以 TSO(Total Store Order)内存模型运行时，sparc处理器的特性。
• 上表中的 x86 包括 x64 及 AMD64。
• 因为 ARM 处理器的内存模型与 PowerPC 处理器的内存模型很是相似，本文将忽 略它。
• 数据依赖性后文会专门说明。

为了保证内存可见性，java 编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM 把<span style="color:blue">内存屏障</span>指令分为下列四类:

屏障类型	指令示例	说明
LoadLoad	Load1;LoadLoad;Load2	确保Load1数据装载在Load2以及Load2以后的装载指令的装载。
StoreStore	Store1;StoreStore;Store2	确保 Store1 数据对其余处理器可见(刷新到内存)，以前于 Store2 及全部后续存储指令的存储。
LoadStore	Load1;LoadStore;Store2	确保 Load1 数据装载，以前于 Store2 及全部后续的存储指令刷 新到内存。
StoreLoad	Store1;StoreLoad;Load2	确保 Store1 数据对其余处理器变 得可见(指刷新到内存)，以前于 Load2 及全部后续装载指令的装 载。StoreLoad Barriers 会使该屏 障以前的全部内存访问指令(存储 和装载指令)完成以后，才执行该 屏障以后的内存访问指令。

StoreLoad屏障类型是一个“全能型”的屏障，它同时具备其余三个屏障的效果。 现代的多处理器大都支持该屏障(其余类型的屏障不必定被全部处理器支持)。执 行该屏障开销会很昂贵，由于当前处理器一般要把写缓冲区中的数据所有刷新到内 存中(buffer fully flush)。

happens-before

从 JDK5 开始，java使用新的JSR-133内存模型(本文除非特别说明，针对的都 是 JSR- 133 内存模型)。JSR-133 使用 happens-before 的概念来阐述操做之间 的内存可见性。

在 JMM 中，若是一个操做执行的结果须要对另外一个操做可见，那 么这两个操做之间必需要存在 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。

注意，两个操做之间具备happens-before关系，并不意味着前一个操做必需要在后一个操做以前执行!happens-before 仅仅要求前一个操做(执行的结果)对后一个操做可见，且前一个操做按顺序排在第二个操做以前(the first is visible to and ordered before the second)。

happens- before 的定义很微妙，后文会具 体说明 happens-before 为何要这么定义。

happens-before 与 JMM 的关系以下图所示:

如上图所示，一个 happens-before 规则对应于一个或多个编译器和处理器重排序 规则。对于 java 程序员来讲，happens-before 规则简单易懂，它避免 java 程序 员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。

总结

这篇文章主要是给你们澄清一些概念，为后续的文章展开分析作好基础工做。主要讲了

• 并发编程模型有哪些
• java内存模型
• java的指令重排序
• jmm的内存屏障
• happens-before和jmm的关系

这篇文章，你们着重理解这些基础概念，并把原理图理清便可。