内存屏障的作用

  1. 确保一些特定操作执行的顺序
  2. 影响一些数据的可见性（其中一种方式就是强制更新一次不同 CPU 的缓存）

可见性

可见性：当一个线程修改了线程共享变量的值，其它线程在使用前，能够得到最新的修改值。

有两种可见性问题：

  1. CPU 在硬件架构上的缓存问题
  2. JVM 在自己维护的内存模型中的问题（可以把工作内存看作是缓存）

可见性导致的伪·重排序（内存屏障解决的问题）

缓存同步顺序本质上是可见性问题。

假设程序顺序（program order）中先更新变量v1、再更新变量v2，不考虑真·重排序：

  1. Core0先更新缓存中的v1，再更新缓存中的v2（位于两个缓存行，这样淘汰缓存行时不会一起写回内存）。
  2. Core0读取v1（假设使用LRU协议淘汰缓存）。
  3. Core0的缓存满，将最远使用的v2写回内存。
  4. Core1的缓存中本来存有v1，现在将v2加载入缓存。

重排序是针对程序顺序而言的，如果指令执行顺序与程序顺序不同，就说明这段指令被重排序了。

此时，尽管“更新v1”的事件早于“更新v2”发生，但Core1只看到了v2的最新值，却看不到v1的最新值。这属于可见性导致的伪·重排序：虽然没有实际上没有重排序，但看起来发生了重排序。

可以看到，缓存可见性不仅仅导致可见性问题，还会导致伪·重排序。因此，只要解决了缓存上的可见性问题，也就解决了伪·重排序。

内存屏障类型

  • Store：将处理器缓存的数据刷新到内存中。
  • Load：将内存存储的数据拷贝到处理器的缓存中。

LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

volatile 中的内存屏障

基于保守策略的JMM内存屏障插入策略：

  • 在每个volatile写操作的前面插入一个StoreStore屏障，后面插入一个StoreLoad屏障。
  • 在每个volatile读操作的前面插入一个LoadLoad屏障，后面插入一个LoadStore屏障。

final 中的内存屏障

深入理解Java内存模型（六）——final-InfoQ

对于 final 域，编译器和处理器要遵守两个重排序规则：

  1. 在构造函数内对一个 final 域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
  2. 初次读一个包含 final 域的对象的引用，与随后初次读这个 final 域，这两个操作之间不能重排序。

写 final 域规则

编译器会在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 屏障。这个屏障禁止处理器把 final 域的写重排序到构造函数之外。

读 final 域规则

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

GC 中的写屏障

并发标记阶段：如果在标记的过程中对一个对象建立新的引用，但是此时清理线程并不知道建立了新的引用，这个时候就会出现漏标的情况，加入写屏障则可以保证清理线程在的对象获取操作必须在主线程的引用建立操作之后执行。