【JMM】内存模型之内存屏障

文章首发于：clawhub.club

---

内存屏障是为了解决在cacheline上的操作重排序问题。

作用：

强制cpu将store buffer中的内容写入到cacheline中
强制cpu将invalidate queue中的请求处理完毕

类型

屏障类型	指令示例	说明
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;Load1	该屏障确保Store1立刻刷新数据到内存的操作先于Load2及其后所有装载装载指令的操作.它会使该屏障之前的所有内存访问指令(存储指令和访问指令)完成之后,才执行该屏障之后的内存访问指令

StoreLoad Barriers同时具备其他三个屏障的效果,因此也称之为全能屏障,是目前大多数处理器所支持的,但是相对其他屏障,该屏障的开销相对昂贵.在x86架构的处理器的指令集中,lock指令可以触发StoreLoad Barriers.

内存屏障在Java中的体现

volatile：

• volatile读之后，所有变量读写操作都不会重排序到其前面。
• volatile读之前，所有volatile读写操作都已完成。
• volatile写之后，volatile变量读写操作都不会重排序到其前面。
• volatile写之前，所有变量的读写操作都已完成。

根据JMM规则，结合内存屏障的相关分析：

• 在每一个volatile写操作前面插入一个StoreStore屏障。这确保了在进行volatile写之前前面的所有普通的写操作都已经刷新到了内存。
• 在每一个volatile写操作后面插入一个StoreLoad屏障。这样可以避免volatile写操作与后面可能存在的volatile读写操作发生重排序。
• 在每一个volatile读操作后面插入一个LoadLoad屏障。这样可以避免volatile读操作和后面普通的读操作进行重排序。
• 在每一个volatile读操作后面插入一个LoadStore屏障。这样可以避免volatile读操作和后面普通的写操作进行重排序。

final：

• 写 final 域的重排序规则
  JMM 禁止编译器把 final 域的写重排序到构造函数之外。
  编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。
• 读 final 域的重排序规则
  在一个线程中，初次读对象引用与初次读该对象包含的 final 域，JMM 禁止处理器重排序这两个操作（注意，这个规则仅仅针对处理器）。编译器会在读 final 域操作的前面插入一个 LoadLoad 屏障。

CAS

在CPU架构中依靠lock信号保证可见性并禁止重排序。
lock前缀是一个特殊的信号，执行过程如下：

• 对总线和缓存上锁。
• 强制所有lock信号之前的指令，都在此之前被执行，并同步相关缓存。
• 执行lock后的指令（如cmpxchg）。
• 释放对总线和缓存上的锁。
• 强制所有lock信号之后的指令，都在此之后被执行，并同步相关缓存。

因此，lock信号虽然不是内存屏障，但具有mfence的语义（当然，还有排他性的语义）。
与内存屏障相比，lock信号要额外对总线和缓存上锁，成本更高。

锁

JVM的内置锁通过操作系统的管程实现。由于管程是一种互斥资源，修改互斥资源至少需要一个CAS操作。因此，锁必然也使用了lock信号，具有mfence的语义。

参考

一文解决内存屏障
内存屏障与 JVM 并发
内存屏障和 volatile 语义
Java内存模型Cookbook（二）内存屏障
谈乱序执行和内存屏障
内存屏障
深入理解 Java 内存模型（六）——final