“java 内存模型的基础认知（一）”
前言
并发编程可以使我们将程序划分为多个分离的、独立运行的任务。通过使用多线程机制，我们可以将这些独立任务（也被称为子任务）由执行线程来进行驱动。而想要让它们之间可以互相协同、正确、有效的工作，就不得不面临两个关键的问题：它们之间该 如何保持通信 和它们之间该 如何保持数据同步。
java 内存模型（以下简称 JMM） 就是为此而生的，它提供了一些规则用来保证多个线程之间可以有效地、正确地协同工作。
而 JMM 的关键技术点都是在围绕着多线程的原子性、可见性和有序性来建立的。blablabla……
正文
好了，前言就此打住，我们先来了解两个基础概念。
- 通信： 通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种:共享内存和消息传递。
在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。 - 同步: 同步是指程序用于控制不同线程之间操作发生相对顺序的机制。
在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。
Java 的并发采用的是共享内存模型，所以 Java 线程之间的通信是隐式进行的，整个通信过程对程序员完全透明。
所以如果编写多线程程序的时候不理解隐式进行的线程之间通信的工作机制，就很可能会遇到各种奇怪的内存可见性问题。
Java 内存模型的抽象
在 java 中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享。但局部变量、方法定义参数（方法行参）和异常处理器参数不会在线程之间共享。因此，它们就不存在内存可见性问题，也不受内存模型的影响。
Java 线程之间的通信是由 JMM 控制的，JMM 决定了一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM 定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存本地内存 中存储了该线程以读/写共享变量的副本。本地内存是 JMM 的一个抽象概念，并不真实存在，它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。
JMM 的抽象示意图：
从上图来看，线程 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 程序员提供内存可见性保证。
但是通常在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。
重排序
现代的处理器会使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。因此，这个特性会对内存操作的执行顺序产生重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！
首先我们来看个例子： | Processor A | Processor B | | —— | —— | | a = 1; //A1
x = b; //A2 | b = 2; //B1
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 一样）。
重排序分为三种类型：
- 编译器优化的重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
- 指令级并行的重排序：现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
- 内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
上面例子便使用了指令级并行的重排序与内存系统的重排序。
从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序:
其中 1 属于编译器重排序，2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。
当然，JMM 也相应地提供了一些对应方案。对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 Java 编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。
JMM 属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器冲排序和处理器重排序，为程序员提供一致的内存可见性保证。
来源：luob 的博客文章
