说明

又发现一本不错的小书《深入理解 Java 内存模型》，趁着昨天周六一口气读完，虽然篇幅只有区区70页，可受益颇多。由于原文短小精悍，为了预留合理的上下文以助于理解，本文保留了大部分原文，并且在关键处使用笔者自己的理解对原文进行再解释（以表达方式再排列、语义扩充等方法，尽量在语义上确保大于等于原意）。好了废话不多说，我们开始吧~

基础

并发编程的分类

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

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。

同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

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

Java 内存模型的抽象

在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

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

Java内存模型抽象示意图

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

线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去
然后，线程 B 到主内存中去读取线程 A 之前已经更新过的共享变量

两个线程通信步骤

举例说明Java线程间通信机制：

以上图为背景，线程 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 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

Java 源码到执行涉及的重排序

其中 1 属于编译器重排序，2 和 3 属于处理器重排序。

这些重排序都可能会导致多线程程序出现内存可见性问题。因此，为了避免此问题，JMM编译器设置了一些规则：

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

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

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

现代处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多的好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！

我们来假设这样一种情况：

Processor A	Processor B
a = 1; //A1 x = b; //A2	b = 2; //B1 y = a; //B2

显然，我们期望得到的执行结果是: x = 2，y = 1。然而实际上，我们却可能得到 x = y = 0，这是为什么呢？

处理器重排序导致的问题

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

从内存操作实际发生的顺序看，直到处理器 A 执行 A3 来刷新自己的写缓存区 A，写操作 A1 才算真正执行了。虽然处理器 A 执行内存操作的顺序为：A1 -> A2，但内存操作实际发生的顺序确是 A2 -> A1。此时，处理器 A 的内存操作顺序被重排序了

处理器 B 和 A 的情况是类似的，这里不赘述了。

产生这个结果的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作顺序不一致。

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

	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 重排序；常见的处理器都不允许对存在数据以来的操作做重排序。特别的，对于 x86 架构的处理器，仅仅会在 Store-Load 这种情况进行重排序。

到这里，有同学可能有疑问了，既然 CPU 肯定会对 Store-Load 这种情况进行重排序，那岂不是乱套了，我 Java 代码怎么写？？

实际上，为了解决这个问题，Java 编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。

JMM 把内存屏障指令分为以下四类：

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

现代处理器大多支持 Store-Load Barriers （其他类型的屏障不一定被所有处理器支持）。但是执行该屏障的开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（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 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。这个定义看起来很微妙，后文具体说明为什么这么定义。

总结下happens-before 与 JMM 的关系，如下图所示：

happens-before与JMM的关系

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

重排序

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时，这两个操作之间就存在数据依赖性。

数据依赖分下列三种类型：

名称	代码示例	说明
写后读	a = 1; b = a;	写一个变量之后，再读这个位置。
写后写	a = 1; a = 2;	写一个变量之后，再写这个变量。
读后写	a = b; b = 1;	读一个变量之后，再写这个变量。

很容易对这三种情况得出如下结论：

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。

前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。也就是说，上面三种情况，不会发生处理器重排序。

不过，这里需要注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑（这种情况参考前面中的例子）

as-if-serial 语义

不管怎么重排序（编译器和处理器为了提升并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守 as-if-serial 语义。

为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。

但是，如果操作之前不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。我们举例说明：

1
2
3

double pi = 3.14;					// A
double r = 1.0;						// B
double area = pi * r * r; // C

上面三个操作的数据依赖关系如下图所示：

三个操作的数据依赖关系

如上图所示，A 和 C 之间存在数据依赖关系，同时 B 和 C 之间也存在数据依赖关系。因此在最终执行的指令序列中，C 不能被重排序到 A 和 B 的前面（因为这种情况下程序结果将被改变）。但 A 和 B 之间是没有数据依赖关系的，编译器和处理器可以重排序 A 和 B 之间的执行顺序。下图是该程序的两种执行顺序：

两种执行顺序

as-if-serial 语义把单线程程序保护了起来，遵守 as-if-serial 语义的编译器、runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序时按程序的顺序来执行的。as-if-serial 语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

程序顺序规则

根据 happens-before 的程序顺序规则，上面计算圆的面积的示例代码存在三个 happens-before 关系：

A happens-before B
B happens-before C
A happens-before C（根据前两个推导出来的，即传递性）

这里 A happens-before B ，但实际执行 B 却可以排在 A 之前执行（看上面那两种重排序后的执行顺序）。在前面提到过，如果 A happens-before B ，JMM 并不要求 A 一定要在 B 之前执行。JMM 仅仅要求前一个操作（执行的结果）对后一个操作可见；而且重排序操作 A 和操作 B 后的执行结果，与操作 A 和 B 按照程序顺序执行的结果一致。在这种情况下，JMM 会认为这种重排序并不非法（not illegal），JMM 允许这种排序。

在计算机中，软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，尽可能的开发并行度。编译器和处理器遵从这一目标，从 happens-before 的定义我们可以看出，JMM 同样遵从这一目标。

重排序对多线程的影响

现在让我们看看，重排序是否会改变多线程程序的执行结果。我们还用一个示例代入：

class RecorderExample {
  int a = 0;
  boolean flag = false;
  
  public void writer() {
    a = 1;              // 1
    flag = true;        // 2
  }
  
  public void reader() {
    if (flag) {         // 3
      int i = a * a;    // 4
      ......
    }
  }
}

flag 变量是一个标记，用来标识变量 a 是否已被写入。这里假设有两个线程 A 和 B，A 首先执行 writer()方法，随后 B 线程接着执行 reader()方法。线程 B 在执行操作 4 时，能否看到线程 A 在操作 1 对共享变量 a 的写入？

答案是：不一定看到。

由于操作 1 和操作 2 没有数据依赖关系，编译器和处理器可以对这两个操作重排序；同样，操作 3 和操作 4 没有数据依赖关系，编译器和处理器也可以对这两个操作重排序。让我们先来看看，当操作 1 和操作 2 重排序时，可能会产生什么效果？

操作1和操作2重排序时，程序执行时序图

注：本文统一用红色的虚箭线标识错误的读操作，用绿色的虚箭线标识正确的读操作

如上图所示，操作 1 和操作 2 做了重排序。程序执行时，线程 A 首先写标记变量 flag，随后线程 B 读这个变量。由于条件判断为真，线程 B 将读取变量 a。此时，变量 a 还根本没有被线程 A 写入，在这里多线程程序的语义被重排序破坏了！

现在再让我们看看，当操作 3 和操作 4 重排序时会产生什么效果（借助这个重排序，可以顺便说明控制依赖性）。如图所示，操作 3 和 4 重排序后，程序的执行时序：

操作3和操作4重排序时，程序执行时序图

在程序中，操作 3 和操作 4 存在控制依赖关系。当代码中存在控制依赖关系时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器猜测执行为例，执行线程 B 的处理器可以提前读取并计算 a*a，然后把计算结果临时保存到另一个名为重排序缓存（record buffer ROB）的硬件缓存中。当接下来操作 3 的条件判断为真时，就把计算结果写入变量 i 中。

显然，此种情况下（如上图所示），猜测执行实质上对操作 3 和 4 做了重排序。重排序在这里破坏了多线程程序的语义！

在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是 as-if-serial 语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

顺序一致性

数据竞争与顺序一致性保证

当程序未正确同步时，就可能会存在数据竞争。Java 内存模型规范对数据竞争的定义如下：

一个线程中写一个变量
在另一个线程读同一个变量
而且写和读没有通过同步来排序

当代码中包含数据竞争时，程序的执行旺旺产生违反直觉的结果（前面的示例正是如此）。如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。

JMM 对正确同步的多线程程序的内存一致性做了如下保证：

如果程序是正确同步的，程序的执行将具有顺序一致性（sequentially consistent），即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。马上我们将会看到，这对于程序员来说是一个极强的保证。这里的同步是指广义上的同步，包括对常用同步原语（synchronized，voliatile 和 final）的正确使用。

顺序一致性内存模型

顺序一一致性模型是一个被计算机科学家理想化了的理论参考模型，它为程序员提供了极强的内存可见性保证。其提供两大特性：

一个线程中的所有操作必须按照程序的顺序来执行
（不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性模型中，每个操作都必须原子执行且立刻对所有线程可见。

顺序一致性内存模型为程序员提供的视图如下：

顺序一致性模型的程序员视图

在概念上，顺序一致性模型有一个单一的全局内存，这个内存通过一个左右摆动的开关可以连接到任意一个线程，同时每一个线程必须按照程序的顺序来执行内存读/写操作。

从上面的示意图我们可以看出：

在任意时间点，最多只有一个线程可以连接到内存。当多个线程并发执行时，图中的开关装置能把所有线程的所有内存读/写操作串行化（即在顺序一致性模型中，所有操作之间具有全序关系）

为了更好的理解，下面我们通过两个示意图来对顺序一致性模型的特性做进一步的说明。

假设有两个线程 A 和 B 并发执行。其中 A 线程有三个操作，他们在程序中的顺序是：A1->A2->A3。B 线程也有三个操作，他们在程序中的顺序是：B1->B2->B3。

假设这两个线程使用监视器来正确同步：A 线程的三个操作执行后释放监视器锁，随后 B 线程获取同一个监视器锁。那么程序在顺序一致性模型中的执行效果将如下图所示：

顺序一致性模型举例1

现在我们再假设两个线程没有做同步，下面是这个未同步程序在顺序一致性模型中的执行示意图：

顺序一致性模型举例2

未同步的程序在顺序一致性模型中虽然整体执行顺序是无序的，但所有线程都只能看到一个一致的整体执行顺序。以上图为例，线程 A 和线程 B 看到的执行顺序都是：B >A1->A2->B2->A3->B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个操作必须立即对任意线程可见。（注意，该模型的不做同步这种情况下保证，JMM 并没有实施）

但是，在 JMM 中就没有这个保证。未同步的程序在 JMM 中不但整体的执行顺序是无序的，而且所有线程看到的操作执行顺序也可能不一致。比如，在当前线程把写过的数据缓存在本地内存中，在还没刷新到主内存之前，这个写操作仅对当前线程可见；从其他线程的角度来观察，会认为这个写操作根本还没有被这个线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后，这个写操作才能对其他线程可见。在这种情况下，当前线程和其他线程看到的操作执行顺序将不一致。

同步程序的顺序一致性效果

下面我们对前面的示例程序 RecordExample 用锁来同步，看看正确同步的程序如何具有顺序一致性。

请看下面的示例代码：

class SynchronizedExample {
  int a = 0;
  Boolean flag = false;
  public synchronized void writer() {
    a = 1;
    flag = true;
  }                                 // 释放锁
  
  public synchronized void reader() {
    if(flag) {
      int i = a;
      ......
    }
  }                                 // 释放锁
}

上面示例代码中，假设 A 线程执行 writer() 方法后，B 线程执行 reader()方法。这是一个正确同步的多线程程序。根据 JMM 规范，该程序的执行结果将与该程序在顺序一致性模型中的执行结果相同。下面是该程序在两个内存模型中的执行时序对比图：

在JMM与顺序一致性模型中执行的对比

在顺序一致性模型中，所有操作完全按程序的顺序串行执行。而在 JMM 中，临界区内的代码可以重排序（但 JMM 不允许临界区的代码“逸出”到临界区之外，那样会破坏监视器的语义。）JMM 会在退出临界区和进入临界区这两个关键时间点做一些特别的处理，使得线程在这两个时间点具有与顺序一致性模型相同的内存视图（具体后文说明）。虽然线程 A 在临界区做了重排序，但由于监视器的互斥执行的特性，这里的线程 B 根本无法“观察”到线程 A 在临界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。

从这里我们可以看到 JMM 在具体实现上的基本方针：在不改变（正确同步）程序执行结果的前提下，尽可能为编译器和处理器的优化打开方便之门。

未同步程序的执行特性

对于未同步或未正确同步的多线程程序，JMM 只提供最小安全性：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，null，false），JMM 保证线程读操作读取到的值不会无中生有（out of thin air）的冒出来。为了实现最小安全性，JMM 在堆上分配对象时，首先会清零内存空间，然后才会在上面分配对象（JVM内部会同步这两个操作）。因此，在已清零的内存空间（pre zeroed memory）分配对象时，域的默认初始化已经完成了。

JMM 不保证未同步的执行结果与该程序在顺序一致性模型中的执行结果一致（这也符合我们的直觉）。因为如果想要保证执行结果一致，JMM 需要禁止大量的处理器和编译器的优化，这对程序的执行性能会产生很大的影响。而且未同步的程序在顺序一致性模型中执行时，整体时无序的，其执行结果往往无法预知。保证未同步程序在这两个模型中的执行结果一致没什么意义。

未同步程序在 JMM 中的执行，整体时无序的，其执行结果无法预知。未同步程序在两个模型中的执行特性有下面几个差异：

顺序一致性模型保证单线程内的操作会按程序的顺序执行，而 JMM 不保证单线程内的操作会按程序的顺序执行（比如上面正确同步的多线程程序在临界区内的重排序）。这一点前面已经讲过了，这里就不再赘述。
顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而 JMM 不保证所有线程能看到一只的操作执行顺序。这一点前面已经讲过了，这里就不再赘述。
JMM 不保证对 64 位的 long 型和 double 型变量的读/写操作具有原子性，而顺序一致性模型保证对所有的内存读/写操作都具有原子性。

第三个差异与处理器总线的工作机制密切相关。在计算机中，数据通过总线在处理器和内存之间传递。每次处理器和内存之间的数据传递都是通过一系列步骤来完成的，这一协力步骤称之为总线事务（bus transaction）。总线事务包括读事务（read transaction）和写事务（write transaction）。读事务从内存传送数据到处理器，写事务从处理器传送数据到内存，每个事务会读/写内存中一个或多个物理上连续的字节。这里的关键是，总线会同步视试图并发使用总线的事务。在一个处理器执行总线事务期间，总线会禁止其他所有的处理器和 I/O 设备执行内存的读/写。

下面我们通过一个示意图来说明总线的工作机制：

总线的工作机制

如上图所示，假设处理器 A、B 和 C 同时向总线发起总线事务，这时总线仲裁（bus arbitration）会对竞争作出裁决，这里我们假设总线在仲裁后判定处理器 A 在竞争者获胜（总线仲裁会确保所有处理器都能公平的访问内存）。此时处理器 A 继续它的总线事务，而其他两个处理器则要等待处理器 A 的总线事务完成后才能开始再次执行内存访问。假设在处理器 A 执行总线事务期间（不管这个总线事务是读事务还是写事务），处理器 D 向总线发起了总线事务，此时处理器 D 的这个请求会被总线禁止。

总线的这些工作机制可以把所有处理器对内存的访问以串行化的方式来执行；在任意时间点，最多只能有一个处理器能访问内存。这个特性确保了单个总线事务之中的内存读/写操作具有原子性。

在一些 32 位的处理器上，如果要求对 64 位数据的写操作具有原子性，会有比较大的开销。为了照顾这种处理器，Java 语言规范鼓励但不强求 JVM 对 64 位的 long 型变量和 double 型变量的写具有原子性。当 JVM 在这种处理器上运行时，会把一个 64 位 long/double 型变量的写操作拆分为两个 32 位的写操作来执行。这两个 32 位的写操作可能会被分配到不同的总线事务中执行，此时对这个 64 位变量的写将不具有原子性。

当单个内存操作不具有原子性，将可能会产生意想不到的后果。请看下面示意图：

单个内存操作不具有原子性产生的后果

如上图所示，假设处理器 A 写一个 long 型变量，同时处理器 B 要读这个 long 型变量。处理器 A 中 64 位的写操作被拆分成两个 32 位的写操作，且这两个 32 位的写操作被分配到不同的写事务中执行。同时处理器 B 中的 64 位读操作被分配到单个读事务中执行。当处理器 A 和 B 按上图的时序来执行时，处理器 B 将看到仅仅处理器 A “写了一半” 的无效值。

注意，在 JSM-133 之前的旧内存模型中，在 32 位处理器上，一个 64 位 long/double 型变量的读/写操作可以被拆分为两个 32 位的读/写操作来执行。从 JSR-133 内存模型开始（即从 JDK5 开始），仅仅只允许把一个 64 位 long/double 型变量的写操作拆分为两个 32 位的写操作执行，任意的读操作在 JSR-133 中都必须具有原子性（即任意读操作必须要在单个读事务中执行）。

volatile

volatile的特性

当我们声明变量为 volatile 后，对这个变量的读/写将会很特别。理解volitile 特性的一个好方法是把对 volatile 变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步。

下面，我们通过具体的示例来说明，请看下面的示例代码：

class VolatileFeaturesExample {
   volatile long vl = 0L;        //使用 volatile 声明 64 位的 long 型变量

   public void set(long l) {
     vl = l;                     //单个 volatile 变量的写
   }

   public void getAndIncrement() {
     vl++;                       //复合（多个）volatile 变量的读/写
   }

   public long get() {
     return vl;                  //单个 volatile 变量的读
   }
 }

假设有多个线程分别调用上面程序的三个方法，这个程序在语义上和下面程序等价：

class VolatileFeaturesExample {
    long vl = 0L;                           // 64 位的 long 型普通变量

    public synchronized void set(long l) {  //对单个的普通变量的写用同一个锁同步
      vl = l;
    }

    public void getAndIncrement() {         //普通方法调用
      long temp = get();                    //调用已同步的读方法
      temp += 1L;                           //普通写操作
      set(temp);                            //调用已同步的写方法
    }

    public synchronized long get() {        //对单个的普通变量的读用同一个锁同步
      return vl;
    }
  }

如上面示例程序所示，对一个 volatile 变量的单个读/写操作，与对一个普通变量的读/写操作使用同一个锁来同步，他们的之间的执行效果相同。

锁的 happens-before 规则保证释放锁和获得锁的两个线程之间的内存可见性，这意味着对一个 volatile 变量的读，总是能看到（任意线程）对这个 volitile 变量最后的写入。

锁的语义决定了临界区代码的执行具有原子性。这意味着即使是 64 位的 long 型和 double 型变量（在 32 位处理器上），只要它是 volatile 变量，对该变量的读写就将具有原子性。如果是多个 volatile 操作或类似于 volatile++这种复合操作，这些操作整体上不具有原子性。

简而言之，volatile 变量自身具有下列特性：

可见性
对一个 volatile 变量的读，总是能看到（任意线程）对这个 volatile 变量最后的写入
原子性
对任意单个 volatile 变量的读/写具有原子性，但类似于 volatile++这种复合操作不具有原子性

深入理解 Java 内存模型

说明

基础