java内存模型 重排序与顺序一致性

目录

重排序

数据依赖性

as-if-serial语义

程序顺序规则

重排序对多线程的影响

顺序一致性

数据竞争与顺序一致性

顺序一致性内存模型

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

未同步程序的执行特性

---

重排序

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间 就存在数据依赖阻数据依赖分为下列3种类型

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

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

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

as-if-serial语义

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程） 程序的执行结果不能被改变。

编译器、runtime和处理器都必须遵守as-if-serial语义。

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

但是，如果操作之间不存在数据依赖关系，这些橾作就可能被 编译器和处理器重排序。为了具体说明，请看下面计算圆面积的代码示例。

上面3个操作的数据依赖关系如图

如图所示，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的程序顺序规则，上面计算圆的面积的示例代码存在3个happens­ before关系。

1) A happens-before B。

2) B happens-before C。

3) A. happens-before C。

这里的第3个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会认为这种重排序并不非法(not illegal), JMM允许这种重排序。

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

重排序对多线程的影响

现在让我们来看看，重排序是否会改变多线程程序的执行结果。请看下面的示例代码。

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

答案是：不一定能看到。

由于橾作1和橾作2没有数据依赖关系，编译器和处理器可以对这两个橾作重排序；

同样， 操作3和橾作4没有数据依赖关系，编译器和处理器也可以对这两个橾作重排序。

让我们先来 看看，当操作1和橾作2重排序时，可能会产生什么效果？请看下面的程序执行时序图如图

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

主意本文统一用虚箭线标识错误的读橾作，用实箭线标识正确的读操作。

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

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

猜测执行实质上对操作3和4做了重排序。重排序在这里破坏了 多线程程序的语义！

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

顺序一致性

顺序一致性内存模型是一个理论参考模型，在设计的时候，处理器的内存模型和编程语 言的内存模型都会以顺序一致性内存模型作为参照。

数据竞争与顺序一致性

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

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

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

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

如果程序是正确同步的，程序的执行将具有顺序一致性(Sequentially Consistent) ：即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。

马上我们就会看到，这对 于程序员来说是一个极强的保证。这里的同步是指广义上的同步，包括对常用同步原语 (synchronized、volatile和final)的正确使用。

顺序一致性内存模型

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

1)一个线程中的所有操作必须按照程序的顺序来执行。

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

注意：JMM并发的共享内存有两大问题：重排序和工作内存导致执行后，对其他线程不可见。

而顺序一致性内存模型，保证解决这两大问题，保证正确同步的线程的共享内存工作正常！

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

在概念上，顺序一致性模型有一个单一的全局内存，这个内存通过一个左右摆动的开关 可以连接到任意一个线程，同时每一个线程必须按照程序的顺序来执行内存读／写操作。从上 面的示意图可以看出，在任意时间点最多只能有一个线程可以连接到内存。当多个线程并发 执行时，图中的开关装置能把所有线程的所有内存读／写操作串行化（即在顺序一致性模型中， 所有橾作之间具有全序关系）。

为了更好进行理解，下面通过两个示意图来对顺序一致性模型的特性做进一步的说明。 假设有两个线程A和B并发执行。其中A线程有3个操作，它们在程序中的顺序是：

Al~A2~A3。B线程也有3个操作，它们在程序中的顺序是： Bl~B2~B3。

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

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

未同步程序在顺序一致性模型中虽然整体执行顺序是无序的，但所有线程都只能看到一 个一致的整体执行顺序。以上图为例，线程A和B看到的执行顺序都是：

Bl~Al~A2~B2~A3~B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个橾 作必须立即对任意线程可见。

但是，在JMM中就没有这个保证。未同步程序在JMM中不但整体的执行顺序是无序的，而 且所有线程看到的操作执行顺序也可能不一致。

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

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

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

请看下面的示例代码。

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

顺序一致性模型中，所有橾作完全按程序的顺序串行执行。

而在JMM中，临界区内的代码 可以重排序（但JMM不允许临界区内的代码“逸出”到临界区之外，那样会破坏监视器的语 义）。JMM会在退出临界区和进入临界区这两个关键时间点做一些特别处理，使得线程在这两 个时间点具有与顺序一致性模型相同的内存视图（具体细节后文会说明）。

虽然线程A在临界 区内做了重排序，但由于监视器互斥执行的特性，这里的线程B根本无法”观察”到线程A在临 界区内的重排序。这种重排序既提高了执行效率，又没有改变程序的执行结果。

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

未同步程序的执行特性

对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到的 值，要么是之前某个线程写入的值，要么是默认值(0, Null, False), JMM保证线程读操作读取 到的值不会无中生有(Out Of Thin Air)的冒出来。

为了实现最小安全性，JVM在堆上分配对象 时，首先会对内存空间进行清零，然后才会在上面分配对象(JVM内部会同步这两个操作）。因 此，在已清零的内存空间(Pre-zeroed Memory)分配对象时，域的默认初始化已经完成了。

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

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

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

第3个差异与处理器总线的工作机制密切相关。在计算机中，数据通过总线在处理器和内 存之间传递。每次处理器和内存之间的数据传递都是通过一系列步骤来完成的，这一系列步骤称之为总线事务(Bus Transaction)。总线事务包括读事务(Read Transaction)和写事务(Write Transaction)。读事务从内存传送数据到处理器，写事务从处理器传送数据到内存，每个事务会 读／写内存中一个或多个物理上连续的字。这里的关键是，总线会同步试图并发使用总线的事 务。在一个处理器执行总线事务期间，总线会禁止其他的处理器和IO设备执行内存的读／写。 下面，让我们通过一个示意图来说明总线的工作机制

由图可知，假设处理器A,B和C同时向总线发起总线事务，这时总线仲裁(Bus Arbitration) 会对竞争做出裁决，这里假设总线在仲裁后判定处理器A在竞争中获胜（总线仲裁会确保所有 处理器都能公平的访问内存）。此时处理器A继续它的总线事务，而其他两个处理器则要等待 处理器A的总线事务完成后才能再次执行内存访问。假设在处理器A执行总线事务期间（不管 这个总线事务是读事务还是写事务），处理器D向总线发起了总线事务，此时处理器D的请求 会被总线禁止。

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

在一些32位的处理器上，如果要求对64位数据的写操作具有原子性，会有比较大的开销。

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

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

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

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