今日分享开始啦，请大家多多指教~

简介：Java 线程之间的通信对程序员完全透明，内存可见性问题很容易困扰 Java 程序员，这一系列几篇文章将揭开 Java 内存模型的神秘面纱。这一系列的文章大致分 4 个部分，分别是：

• Java 内存模型基础，主要介绍内存模型相关基本概念。

• Java 内存模型中的顺序一致性，主要介绍重排序与顺序一致性内存模型。

• 同步原语，主要介绍三个同步原语(synchronized、volatile 和 final)的内存语义及重排序规则在处理器中的实现。

• Java 内存模型的设计，主要介绍 Java 内存模型的设计原理，及其与处理器内存模型和顺序一致性内存模型的关系。

一、Java 内存模型的基础

1.1 并发编程模型的两个关键问题

在并发编程中需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信——线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

• 共享内存：线程之间共享程序的公共状态，通过读写内存中的公共转台进行隐式通信

• 消息传递：线程之间没有公共状态，线程之间必须通过发送消息来显式进行通信

同步——程序中用于控制不同线程键操作发生相对顺序的机制。

• 共享内存：同步是显式进行的，由于程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行

• 消息传递：同步是隐式进行的，由于消息的发送必须在消息的接收之前。

总结：

Java 的并发采用的是共享内存模型，Java 线程之间的通信总是隐式进行，整个通信过程对程序员完全透明，如果编写多线程程序的 Java 程序员不理解隐式进行线程之间的通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。

1.2 Java 内存模型的抽象结构

Java 中所有的实例域、静态域和数组元素都存储在堆内存中，堆内存在线程之间共享（文章中用“共享变量”指代）。局部变量(Local Variables)、方法定义参数(Formal Method Parameters)和异常处理器参数(Exception Handler Parameters)不会在线程之间共享，它们不会存在内存可见性问题，因此也不受内存模型的影响。

​Java 线程之间的通信由 Java 内存模型(JMM)控制，JMM 决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM 定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存(Local Memory)，本地内存中存储了该线程以读/写共享变量的副本。本地内存是 JMM 的一个抽象概念，并不真实存在。JMM 涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

Java 内存模型的抽象示意图

从上图来看，线程 A 和线程 B 之间要通信的话，必须经历下面 2 个步骤。

1. 线程 A 把本地内存 A 中更新过的变量刷新到主内存中

2. 线程 B 到主内存中去读取线程 A 之前已更新过的共享变量

线程之间通信示意图

如上图所示，本地内存 A 和本地内存 B 在主内存中共享变量 X 的副本。假设初始时，这三个内存中的 X 的值都是 0.线程 A 在执行时，把更新后的 X 的值（假设值为 1）临时存放在自己的本地内存 A 中。当线程 A 和线程 B 需要通信时，线程 A 首先把自己本地内存中修改后的 X 刷新到主内存中，此时主内存中的 X 值变为了 1.随后，线程 B 到主内存中去读取线程 A 更新后的 X 值，此时线程 B 的本地内存 X 的值也更新成了 1。

从整体来看，这两个步骤实质上是线程 A 在向线程 B 发送消息，而且这个通信过程必须要经过主内存。JMM 通过控制主内存与每个线程的本地内存之间的交互，来为 Java 程序员提供内存可见性保证。

1.3 从源代码到指令重排序

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。重排序分为三种类型：

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

2. 指令级并行的重排序。现代处理器采用了指令级并行技术(Instruction-Level Parallelism,ILP)来将对跳指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应及其指令的执行顺序。

3. 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从 Java 源代码的最终实际执行的指令序列，会分别经历下面 3 种重排序，其中 1 属于编译器重排序，2 和 3 属于处理器重排序。

源代码到最终执行的指令序列示意图

重排序可能会导致多线程程序出现内存可见性问题，对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都需要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 Java 编译器在生成指令序列时，插入特定类型的内存屏障（Memory Barries, Intel 称之为 Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

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

1.4 写缓冲区和内存屏障

1.4.1 写缓冲区

现代处理器都会使用写缓冲区临时保存向内存中写入的数据。写缓冲区的主要作用：

• 可以保证指令流水线持续运行，可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。

• 它以批处理的方式方式刷新写缓冲区，以及合并写缓冲区中对统一地址的多次写，减少对内存总线的占用。

常见处理器允许的重排序类型（Y-表示允许两个操作重排序，N-表示处理器不允许两个操作重排序）

说明：常见处理器都允许 Store-Load 重排序；常见的处理器都不允许对存在数据依赖性的操作做重排序。N 多的表示处理器拥有相对较强的处理器内存模型。

由于写缓冲器仅仅只对它所在的处理器可见，这个特性会对内存操作的执行顺序产生非常重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致。

举例说明：

假设处理器 A 和处理器 B 按程序的顺序并行执行内存访问，最终可能得到 x=y=0 的结果，具体原因如下：

处理器和内存交互示意图

说明：处理器 A 和处理器 B 可以同时把共享变量写入自己的写缓冲区（A1、B1），然后从内存中读取另一个共享变量（A2、B2），最后才把自己写缓冲区中保存的脏数据刷新到内存中（A3、B3）。当以这种时序执行时，程序就可以得到 x=y=0 结果。

1.4.2 内存屏障

为了保证内存可见性，Java 编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM 把内存屏障指令分为 4 类：

StoreLoad Barriers 是一个“全能型屏障”，它同时具有其它 3 个屏障的效果。现代大多数处理器支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为处理器需要把缓冲区的内容全部刷新到内存中（Buffer Fully Flush）。

1.5 happens-before 简介

从 JDK1.5 开始，Java 使用新的 JSR-133 内存模型。JSR-133 使用 happens-before 的概念来阐述操作之间的内存可见性。在 JMM 中，如果一个操作的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before 关系。这里的两个操作可以是单线程也可以是多线程。

happens-before 规则：

• 程序顺序规则：一个线程中的每个操作，happens-before 于该线程的任意后续操作。

• 监视器锁规则：对于一个锁的解锁，happens-before 于随后对这个锁的加锁。

• volatile 变量规则：对于一个 volitale 域的写，happens-before 于任意后续对这个 volatile 域的读。

• 传递性：如果 A happens-before B，且 B happens-before C ，那么 A happens-before C。

​注意：

两个操作之间具有 happens-before 关系，并不意味着前一个操作必须在后一个操作之前执行！happens-before 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visiable to and ordered beofre the second）。

图示 happens-before 与 JMM 的关系

happens-before 与 JMM 的关系

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

今日份分享已结束，请大家多多包涵和指点！