一、并发编程模型分类
并发编程要处理的两个问题：（这里的线程是指并发执行活动的实体）
线程之间如何通信：通信是指线程之间以何种机制来交换 信息。
线程之间如何同步：同步是指程序用于控制不同线程之间操作发生相对顺序的机制。
由这两个问题引出并发编程的两个模型
共享内存并发模型
消息传递并发模型
1.1 共享内存
解决通信
在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。
解决同步
在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。
1.2 消息传递
解决通信
在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。
解决同步
消息传递的并发模型里，由于消息的发送必须在消息的接收之前， 因此同步是隐式进行的。
1.3 Java的并发采用模型
Java的并发采用的是共享内存模型；
Java 线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的我们不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。
二、Java内存模型（JMM）的抽象
在java中，所有实例域、静态域和数组元素存储在堆内存中；
堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）；
局部变量 （Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响；
Java 线程之间的通信由Java内存模型（本文简称为 JMM）控制，JMM 决定一个 线程对共享变量的写入何时对另一个线程可见；
从抽象的角度来看，JMM 定义了 线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本；
本地内存是 JMM 的一个抽象概念，并不 真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化；
Java 内存模型的抽象示意图如下：
从上图来看，线程 A 与线程 B 之间如要通信的话，必须要经历下面 2 个步骤：
- 首先，线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去；
- 然后，线程 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 程序员提供内存可见性保证。
三、 重排序
在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。
重排序分三 种类型：
编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
上述的 1 属于编译器重排序；2 和 3 属于处理器重排序；
这些重排序都可能会导致多线程程序出现内存可见性问题；
对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）；
对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类 型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）；
JMM 属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上， 通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。
四、处理器重排序与内存屏障指令
现代的处理器使用写缓冲区来临时保存向内存写入的数据。
写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟；
同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用；
虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致；
为了具体说明，请看下面示例：
| 处理器A | 处理器B |
| a = 1 // A1 | b = 2 // B1 |
| x = b // A2 | y = a // B2 |
初始状态：a = b = 0
处理器允许执行后得到结果：x = y = 0
假设处理器 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 一样，这里就不赘述了）。
这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。
由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写-读操作重排序。
下面是常见处理器允许的重排序类型的列表：
Load（读）
Store（写）
Load-Load |
Load-Store | Store-Store | Store-Load | 数据依赖 | |
| sparc-TSO | N | N | N | Y | N |
| x86 | N | N | N | Y | N |
| ia64 | Y | Y | Y | Y | N |
| PowerPC | Y | Y | Y | Y | N |
上表单元格中的“N”表示处理器不允许两个操作重排序，“Y”表示允许重排 序；
从上表我们可以看出：常见的处理器都允许 Store-Load 重排序；
常见的处理器都 不允许对存在数据依赖的操作做重排序。sparc-TSO 和 x86 拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。
※注 1：sparc-TSO 是指以 TSO(Total Store Order)内存模型运行时，sparc 处理 器的特性。
※注 2：上表中的 x86 包括 x64 及 AMD64。
※注 3：由于 ARM 处理器的内存模型与 PowerPC 处理器的内存模型非常类似，本文将忽 略它。
※注 4：数据依赖性后文会专门说明。
为了保证内存可见性，java 编译器在生成指令序列的适当位置会插入内存屏障指令 来禁止特定类型的处理器重排序。
JMM 把内存屏障指令分为下列四类：
StoreLoad Barriers 是一个“全能型”的屏障，它同时具有其他三个屏障的效果。
现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。
五、happens-before（发生之前）
从 JDK5 开始，java 使用新的 JSR -133 内存模型（本文除非特别说明，针对的都 是 JSR- 133 内存模型）；
JSR-133 使用 happens-before 的概念来阐述操作之间的内存可见性；
在 JMM 中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在 happens-before 关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间；
与程序员密切相关的 happens-before 规则如下：
程序顺序规则：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
这个还是非常好理解的，比如上面那三行代码，第一行的 "double pi = 3.14; " happens-before 于 “double r = 1.0;”，这就是规则1的内容，比较符合单线程里面的逻辑思维，很好理解。
double pi = 3.14; // A double r = 1.0; // B double area = pi * r * r; // C
监视器锁规则：对一个监视器的解锁，happens- before 于随后对这个监视器的加锁。
这个规则中说的锁其实就是Java里的 synchronized。例如下面的代码，在进入同步块之前，会自动加锁，而在代码块执行完会自动释放锁，加锁以及释放锁都是编译器帮我们实现的。
synchronized (this) { //此处自动加锁 // x是共享变量,初始值=10 if (this.x < 12) { this.x = 12; } } //此处自动解锁
所以结合锁规则，可以理解为：假设 x 的初始值是 10，线程 A 执行完代码块后 x 的值会变成 12（执行完自动释放锁），线程 B 进入代码块时，能够看到线程 A 对 x 的写操作，也就是线程 B 能够看到 x==12。这个也是符合我们直觉的，非常好理解。
volatile变量规则：对一个 volatile 域的写，happens- before 于任意后续对 这个 volatile 域的读。
这个就有点费解了，对一个 volatile 变量的写操作相对于后续对这个 volatile 变量的读操作可见，这怎么看都是禁用缓存的意思啊，貌似和 1.5 版本以前的语义没有变化啊（1.5版本前允许volatile变量和普通变量之间重排序）？如果单看这个规则，的确是这样，但是如果我们关联一下规则 4，你就能感受到变化了
传递性：如果 A happens- before B，且 B happens- before C，那么 A happens- before C。
我们将规则 4 的传递性应用到我们下面的例子中，会发生什么呢？
class VolatileExample { int x = 0; volatile boolean v = false; public void writer() { x = 42; v = true; } public void reader() { if (v == true) { // 这里x会是多少呢？ } } }
可以看下面这幅图：
从图中，我们可以看到：
“x=42” Happens-Before 写变量 “v=true” ，这是规则 1 的内容；
写变量“v=true” Happens-Before 读变量 “v=true”，这是规则 3 的内容 。
再根据这个传递性规则，我们得到结果：“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 语义来搞定可见性的。
start()规则：这条是关于线程启动的。它是指主线程 A 启动子线程 B 后，子线程 B 能够看到主线程在启动子线程 B 前的操作。
join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
通过上面6中 happens-before 规则的组合就能为我们程序员提供一致的内存可见性。 常用的就是规则1和其他规则结合，为我们编写并发程序提供可靠的内存可见性模型。
注意，两个操作之间具有 happens-before 关系，并不意味着前一个操作必须要在后一个操作之前执行！
happens-before关系的定义如下：
如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。
上面的1）是JMM对程序员的承诺。 从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！
上面的2）是JMM对编译器和处理器重排序的约束原则。 正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序）编译器和处理器怎么优化都行。JMM这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变（即执行结果不能被改变）。因此，happens-before关系本质上和as-if-serial语义是一回事。
happens- before 的定义很微妙，后面会具体说说 happens-before 为什么要这么定义。
happens-before 与 JMM 的关系如下图所示：
如上图所示，一个 happens-before 规则对应于一个或多个编译器和处理器重排序 规则；
JMM的设计分为两部分：
一部分是面向我们程序员提供的，也就是happens-before规则，它通俗易懂的向我们程序员阐述了一个强内存模型，我们只要理解 happens-before规则，就可以编写并发安全的程序了。
另一部分是针对JVM实现的，为了尽可能少的对编译器和处理器做约束，从而提高性能，JMM在不影响程序执行结果的前提下对其不做要求，即允许优化重排序。 我们只需要关注前者就好了，也就是理解happens-before规则。毕竟我们是做程序员的，术业有专攻，能写出安全的并发程序就好了。
对于 java 程序员来说，happens-before 规则简单易懂，它避免 java 程序员为了理解 JMM 提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现；
结束语
- 由于博主才疏学浅，难免会有纰漏，假如你发现了错误或偏见的地方，还望留言给我指出来，我会对其加以修正。
- 如果你觉得文章还不错，你的转发、分享、点赞、留言就是对我最大的鼓励。
- 感谢您的阅读，十分欢迎并感谢您的关注。
