JMM中的重排序及内存屏障

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。为了实现某些功能有时会禁止某些重排序，由此引入了内存屏障。

 

一、重排序

重排序虽然可以提高程序性能，但是编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。

即：编译器和处理器在重排序时，会遵守数据依赖性。

 

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

 

（1）as-if-serial语义

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

 

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

 

（2）重排序的种类

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

 

（3）从Java源代码到最终实际执行的指令序列，会分别经历下面3中重排序

源代码 -> 1：编译器优化重排序 -> 2：指令级并行重排序 -> 3：内存系统重排序 -> 最终执行的指令序列。

 

其中1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器，JMM编译器重排序规则会禁止特性类型的编译器重排序（并不是所有的编译器重排序都要禁止）; 对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特性类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

 

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

 

二、内存屏障

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

 

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

 

（1）处理器的重排序规则

可以发现常见的处理器都允许StoreLoad重排序; 常见的处理器都不允许对存在数据依赖的操作做重排序。SPARC-TSO和X86拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。

 

（2）内存屏障类型表

为了保证内存可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。

StoreLoad Barriers是一个"全能型"的屏障，它同时具有其他3个屏障的效果。现代的多处理器大多支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（Buffer Fully Flush）。

 

三、总结

重排序可以提高性能，但是重排序可能会导致内存可见性问题，问了解决这个问题，编译器在生成字节码的时候会插入特定类型的内存屏障来禁止重排序，保证多线程下的内存可见性。