Java内存模型 | Hi 高虎

JVM

Java

发布日期: 2018-01-22

作者: 高虎

文章字数: 4.5k

阅读时长: 15 分

阅读次数:

Java内存模型的定义

在多核系统中,处理器一般有一层或者多层的缓存,这些的缓存通过加速数据访问（因为数据距离处理器更近）和降低共享内存在总线上的通讯（因为本地缓存能够满足许多内存操作）来提高CPU性能.缓存能够大大提升性能,但是它们也带来了许多挑战.例如，当两个CPU同时检查相同的内存地址时会发生什么?在什么样的条件下它们会看到相同的值?

在处理器层面上，内存模型定义了一个充要条件，“让当前的处理器可以看到其他处理器写入到内存的数据”以及“其他处理器可以看到当前处理器写入到内存的数据”。有些处理器有很强的内存模型(strong memory model)，能够让所有的处理器在任何时候任何指定的内存地址上都可以看到完全相同的值。而另外一些处理器则有较弱的内存模型（weaker memory model），在这种处理器中，必须使用内存屏障（一种特殊的指令）来刷新本地处理器缓存并使本地处理器缓存无效，目的是为了让当前处理器能够看到其他处理器的写操作或者让其他处理器能看到当前处理器的写操作。这些内存屏障通常在lock和unlock操作的时候完成。内存屏障在高级语言中对程序员是不可见的。

在强内存模型下，有时候编写程序可能会更容易，因为减少了对内存屏障的依赖。但是即使在一些最强的内存模型下，内存屏障仍然是必须的。设置内存屏障往往与我们的直觉并不一致。近来处理器设计的趋势更倾向于弱的内存模型，因为弱内存模型削弱了缓存一致性，所以在多处理器平台和更大容量的内存下可以实现更好的可伸缩性

“一个线程的写操作对其他线程可见”这个问题是因为编译器对代码进行重排序导致的。例如，只要代码移动不会改变程序的语义，当编译器认为程序中移动一个写操作到后面会更有效的时候，编译器就会对代码进行移动。如果编译器推迟执行一个操作，其他线程可能在这个操作执行完之前都不会看到该操作的结果，这反映了缓存的影响。

此外，写入内存的操作能够被移动到程序里更前的时候。在这种情况下，其他的线程在程序中可能看到一个比它实际发生更早的写操作。所有的这些灵活性的设计是为了通过给编译器，运行时或硬件灵活性使其能在最佳顺序的情况下来执行操作。在内存模型的限定之内，我们能够获取到更高的性能。

Java内存模型的抽象

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

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

首先，线程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程序员提供内存可见性保证。

指令重排序

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

编译器优化的重排序，编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序
指令级并行的重排序，现代处理器采用了指令级的并行计算来将多条指令重叠执行，如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序，由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

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

1属于编译器重排序，2和3属于处理器重排序，这些重排序都可能会导致多线程程序出现内存可见性问题，对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序，对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序

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

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

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

示例：

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 一样，这里就不赘述了）。

这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写 - 读操做重排序。

happens-before

从 JDK5 开始，java 使用新的 JSR -133 内存模型（本文除非特别说明，针对的都是 JSR- 133 内存模型）。JSR-133 提出了 happens-before 的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 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 为什么要这么定义。

数据依赖性

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

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

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

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

编译器和处理器可能会对操作做重排序，编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作对的执行顺序。

注意：这里所所的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial 语义

as-if-serial 语义的意思是指:不管怎么重排序(编译器和处理器为了提高并行度)，(单线程)程序的执行结果都不会被改变，编译器，runtime和处理器都必须遵循as-if-serial语义。

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

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

上述依赖关系为 A ,B => C ，A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系，因此在最终执行的指令序列中，C不能被重排序到A和B的前面，因为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

这里的第三个happens-before关系，是根据happens-before的传递性推导出来的。

这里A happens-before B，但实际执行时B却可以排在A之前执行，如果A happens-before B，JMM并不要求A一定要在B之前执行，JMM仅仅要求前一个操作对后一个操作可见，且前一个操作按顺序排在第二个操作之前，这里操作A的执行结果不需要对操作B可见，而且重排序操作A和操作B后执行的结果，与操作A和操作B 按happens-before顺序执行的结果一致，在这种情况下，JMM会认为这种重排序并不非法，JMM允许这种重排序。

重排序对多线程的影响

实例代码

class ReorderExample {
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做了重排序，程序执行时，线程A首先写标记变量flag，随后线程B读这个变量，由于条件判断为真，线程B将读取变量a,此时，变量a还根本没有被线程A写入，在这里多线程程序的语义被重排序破坏了。

再看看操作3和4 重排序会有什么影响。

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