内存屏障与JVM并发

内存屏障为何重要？对主存的一次访问一般花费硬件的数百次时钟周期。处理器通过缓存（caching）能够从数量级上降低内存延迟的成本这些缓存为了性能重新排列待定内存操 作的顺序。也就是说，程序的读写操作不一定会按照它要求处理器的顺序执行。当数据是不可变的，同时/或者数据限制在线程范围内，这些优化是无害的。如果把 这些优化与对称多处理（symmetric multi-processing）和共享可变状态（shared mutable state）结合，那么就是一场噩梦。当基于共享可变状态的内存操作被重新排序时，程序可能行为不定。一个线程写入的数据可能被其他线程可见，原因是数据 写入的顺序不一致。适当的放置内存屏障通过强制处理器顺序执行待定的内存操作来避免这个问题。

内存屏障的协调作用内存屏障不直接由JVM暴露，相反它们被JVM插入到指令序列中以维持语言层并发原语的语义。我们研究几个简单Java程序的源代码和汇编指令。首先快速 看一下Dekker算法中的内存屏障。该算法利用volatile变量协调两个线程之间的共享资源访问。

请不要关注该算法的出色细节。哪些部分是相关的？每个线程通过发信号试图进入代码第一行的关键区域。如果线程在第三行意识到冲突（两个线程都要访问），通 过turn变量的操作来解决。在任何时刻只有一个线程可以访问关键区域。

硬件优化可以在没有内存屏障的情况下打乱这段代码，即使编译器按照程序员的想法顺序列出所有的内存操作。考虑第三、四行的两次顺序volatile读操 作。每一个线程检查其他线程是否发信号想进入关键区域，然后检查轮到谁操作了。考虑第12、13行的两次顺序写操作。每一个线程把访问权释放给其他线程， 然后撤销自己访问关键区域的意图。读线程应该从不期望在其他线程撤销访问意愿后观察到其他线程对turn变量的写操作。这是个灾难。但是如果这些变量没有 volatile修饰符，这的确会发生！例如，没有volatile修饰符，第二个线程在第一个线程对turn执行写操作（倒数第二行）之前可能会观察到 第一个线程对intentFirst(倒数第一行)的写操作。关键词volatile避免了这种情况，因为它在对turn变量的写操作和对 intentFirst变量的写操作之间创建了一个先后关系。编译器无法重新排序这些写操作，如果必要，它会利用一个内存屏障禁止处理器重排序。让我们来 看看一些实现细节。

PrintAssembly HotSpot选项是JVM的一个诊断标志，允许我们获取JIT编译器生成的汇编指令。这需要最新的OpenJDK版本或者新HotSpot update14或者更高版本。通过需要一个反编译插件。Kenai项目提供了用于Solaris、Linux和BSD的插件二进制文件。hsdis是另 一款可以在Windows通过源码构建的插件。

两次顺序读操作的第一次（第三行）的汇编指令如下。指令流基于Itanium 2多处理硬件、JDK 1.6 update 17。本文的所有指令流都在左手边以行号标记。相关的读操作、写操作和内存屏障指令都以粗体标记。建议读者不要沉迷于每一行指令。

简短的指令流其实内容丰富。第一次volatile位于第二行。Java内存模型确保了JVM会在第二次读操作之前将第一次读操作交给处理器，也就是按照 “程序的顺序”——但是这单单一行指令是不够的，因为处理器仍然可以自由乱序执行这些操作。为了支持Java内存模型的一致性，JVM在第一次读操作上添 加了注解ld.acq，也就是“载入获取”（load acquire）。通过使用ld.acq，编译器确保第二行的读操作在接下来的读操作之前完成。问题就解决了。

请注意这影响了读操作，而不是写。内存屏障强制读或写操作顺序限制不是单向的。强制读和写操作顺序限制的内存屏障是双向的， 类似于双向开的栅栏。使用ld.acq就是单向内存屏障的例子。

一致性具有两面性。如果一个读线程在两次读操作之间插入了内存屏障而另外一个线程没有在两次写操作之间添加内存屏障又有什么用呢？线程为了协调，必须同时 遵守这个协议，就像网络中的节点或者团队中的成员。如果某个线程破坏了这个约定，那么其他所有线程的努力都白费。Dekker算法的最后两行代码的汇编指 令应该插入一个内存屏障，两次volatile写之间。

这里我们可以看到在第四行第二次写操作被注解了一个显式内存屏障。通过使用st.rel，即“存储释放”（store release），编译器确保第一次写操作在第二次写操作之前完成。这就完成了两边的约定，因为第一次写操作在第二次写操作之前发生。

st.rel屏障是单向的——就像ld.acq一样。但是在第五行编译器设置了一个双向内存屏障。mf指令，或者称为“内存栅栏”，是Itanium 2指令集中的完整栅栏。笔者认为是多余的。

内存屏障是特定于硬件的本文不想针对所有内存屏障做一综述。这将是一件不朽的功绩。但是，重要的是认识到这些指令在不同的硬件体系中迥异。下面的指令是连续写操作在多处理 Intel Xeon硬件上编译的结果。本文后面的所有汇编指令除非特殊声明否则都出自于Intel Xeon。

我们可以看到x86 Xeon在第11、12行执行两次volatile写操作。第二次写操作后面紧跟着mfence操作——显式的双向内存屏障。

下面的连续写操作基于SPARC。

我们看到在第五、六行存在两次volatile写操作。第二次写操作后面是一个membar指令——显式的双向内存屏障。

x86和SPARC的指令流与Itanium的指令流存在一个重要区别。JVM在x86和SPARC上通过内存屏障跟踪连续写操作，但是在两次写操作之间 没有放置内存屏障。另一方面，Itanium的指令流在两次写操作之间存在内存屏障。为何JVM在不同的硬件架构之间表现不一？因为硬件架构都有自己的内 存模型，每一个内存模型有一套一致性保障。某些内存模型，如x86和SPARC等，拥有强大的一致性保障。另一些内存模型，如Itanium、 PowerPC和Alpha，是一种弱保障。例如，x86和SPARC不会重新排序连续写操作——也就没有必要放置内存屏障。Itanium、 PowerPC和Alpha将重新排序连续写操作——因此JVM必须在两者之间放置内存屏障。JVM使用内存屏障减少Java内存模���和硬件内存模型之间 的距离。

隐式内存屏障显式屏障指令不是序列化内存操作的唯一方式。让我们再看一看Counter类这个例子。