内存屏障*

内存屏障是硬件之上、操作系统或JVM之下，对并发作出的最后一层支持。再向下是是硬件提供的支持；向上是操作系统或JVM对内存屏障作出的各种封装。内存屏障是一种标准，各厂商可能采用不同的实现。

JVM提供的并发机制。首先，从volatile的语义引出可见性与重排序问题；接下来，阐述问题的产生原理，了解为什么需要内存屏障；然后，浅谈内存屏障的标准、厂商对内存屏障的支持，并以volatile为例讨论内存屏障如何解决这些问题；最后，补充介绍JVM在内存屏障之上作出的几个封装。为了帮助理解，会简要讨论硬件架构层面的一些基本原理（特别是CPU架构），但不会深入实现机制。

内存屏障（Memory Barrier）与内存栅栏（Memory Fence）是同一个概念，不同的叫法。

通过volatile标记，可以解决编译器层面的可见性与重排序问题。而内存屏障则解决了硬件层面的可见性与重排序问题。

先简单了解两个指令：

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

StoreLoad Barriers同时具备其他三个屏障的效果，因此也称之为全能屏障（mfence），是目前大多数处理器所支持的；但是相对其他屏障，该屏障的开销相对昂贵。

然而，除了mfence，不同的CPU架构对内存屏障的实现方式与实现程度非常不一样。相对来说，Intel CPU的强内存模型比DEC Alpha的弱复杂内存模型（缓存不仅分层了，还分区了）更简单。x86架构是在多线程编程中最常见的，下面讨论x86架构中内存屏障的实现。

x86架构并没有实现全部的内存屏障。

sfence指令实现了Store Barrier，相当于StoreStore Barriers。

强制所有在sfence指令之前的store指令，都在该sfence指令执行之前被执行，发送缓存失效信号，并把store buffer中的数据刷出到CPU的L1 Cache中；所有在sfence指令之后的store指令，都在该sfence指令执行之后被执行。即，禁止对sfence指令前后store指令的重排序跨越sfence指令，使所有Store Barrier之前发生的内存更新都是可见的。

这里的“可见”，指修改值可见（内存可见性）且操作结果可见（禁用重排序）。下同。

内存屏障的标准中，讨论的是缓存与内存间的相干性，实际上，同样适用于寄存器与缓存、甚至寄存器与内存间等多级缓存之间。x86架构使用了MESI协议的一个变种，由协议保证三层缓存与内存间的相关性，则内存屏障只需要保证store buffer（可以认为是寄存器与L1 Cache间的一层缓存）与L1 Cache间的相干性。下同。

lfence指令实现了Load Barrier，相当于LoadLoad Barriers。

强制所有在lfence指令之后的load指令，都在该lfence指令执行之后被执行，并且一直等到load buffer被该CPU读完才能执行之后的load指令（发现缓存失效后发起的刷入）。即，禁止对lfence指令前后load指令的重排序跨越lfence指令，配合Store Barrier，使所有Store Barrier之前发生的内存更新，对Load Barrier之后的load操作都是可见的。

mfence指令实现了Full Barrier，相当于StoreLoad Barriers。

mfence指令综合了sfence指令与lfence指令的作用，强制所有在mfence指令之前的store/load指令，都在该mfence指令执行之前被执行；所有在mfence指令之后的store/load指令，都在该mfence指令执行之后被执行。即，禁止对mfence指令前后store/load指令的重排序跨越mfence指令，使所有Full Barrier之前发生的操作，对所有Full Barrier之后的操作都是可见的。

在编译器层面，仅将volatile作为标记使用，取消编译层面的缓存和重排序。

如果硬件架构本身已经保证了内存可见性（如单核处理器、一致性足够的内存模型等），那么volatile就是一个空标记，不会插入相关语义的内存屏障。

如果硬件架构本身不进行处理器重排序、有更强的重排序语义（能够分析多核间的数据依赖）、或在单核处理器上重排序，那么volatile就是一个空标记，不会插入相关语义的内存屏障。

如果不保证，仍以x86架构为例，JVM对volatile变量的处理如下：

在写volatile变量v之后，插入一个sfence。这样，sfence之前的所有store（包括写v）不会被重排序到sfence之后，sfence之后的所有store不会被重排序到sfence之前，禁用跨sfence的store重排序；且sfence之前修改的值都会被写回缓存，并标记其他CPU中的缓存失效。在读volatile变量v之前，插入一个lfence。这样，lfence之后的load（包括读v）不会被重排序到lfence之前，lfence之前的load不会被重排序到lfence之后，禁用跨lfence的load重排序；且lfence之后，会首先刷新无效缓存，从而得到最新的修改值，与sfence配合保证内存可见性。

在另外一些平台上，JVM使用mfence代替sfence与lfence，实现更强的语义。

二者结合，共同实现了Happens-Before关系中的volatile变量规则。

除volatile外，常见的JVM实现还基于内存屏障作了一些其他封装。借助于内存屏障，这些封装也得到了内存屏障在可见性与重排序上的语义。

借助：piggyback。

在JVM中，借助通常指：将Happens-Before的程序顺序规则与其他某个顺序规则（通常是监视器锁规则、volatile变量规则）结合起来，从而对某个未被锁保护的变量的访问操作进行排序。

本文将借助的语义扩展到更大的范围，可以借助任何现有机制，以获得现有机制的某些属性。当然，并不是所有属性都能被借助，比如原子性。但基于前文对内存屏障的分析可知，可见性与重排序是可以被借助的。

下面仍基于x86架构讨论。

如果一个实例的字段被声明为final，则JVM会在初始化final变量后插入一个sfence。

类的final字段在()方法中初始化，其可见性由JVM的类加载过程保证。

final字段的初始化在()方法中完成。sfence禁用了sfence前后对store的重排序，且保证final字段初始化之前（include）的内存更新都是可见的。

上述良好性质被称为“初始化安全性”。它保证，对于被正确构造的对象，所有线程都能看到构造函数给对象的各个final字段设置的正确值，而不管采用何种方式来发布对象。

这里将可见性从“final字段初始化之前（include）的内存更新”缩小到“final字段初始化”。猴子没找到确切的原因，手里暂时只有一个jdk也不方便验证。可能是因为，JVM没有要求虚拟机实现在生成()方法时编排字段初始化指令的顺序。

初始化安全性为解决部分初始化问题带来了新的思路：如果待发布对象的所有域都是final修饰的，那么可以防止对对象的初始引用被重排序到构造过程完成之前。于是，面试中单例模式有几种写法？中的饱汉变种三还可以扔掉volatile，改为借助final的sfence语义：

// 饱汉
// ThreadSafe
public class Singleton1_3 {
  private static Singleton1_3 singleton = null;
  
  public int f1 = 1;   // 触发部分初始化问题
  public int f2 = 2;

  private Singleton1_3() {
  }

  public static Singleton1_3 getInstance() {
    if (singleton == null) {
      synchronized (Singleton1_3.class) {
        // must be a complete instance
        if (singleton == null) {
          singleton = new Singleton1_3();
        }
      }
    }
    return singleton;
  }
}

注意，初始化安全性仅针对安全发布中的部分初始化问题，与其他安全发布问题、发布后的可见性问题无关。

在x86架构上，CAS被翻译为"lock cmpxchg..."。cmpxchg是CAS的汇编指令。在CPU架构中依靠lock信号保证可见性并禁止重排序。

lock前缀是一个特殊的信号，执行过程如下：

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

因此，lock信号虽然不是内存屏障，但具有mfence的语义（当然，还有排他性的语义）。

与内存屏障相比，lock信号要额外对总线和缓存上锁，成本更高。

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

锁的mfence语义实现了Happens-Before关系中的监视器锁规则。

CAS具有同样的mfence语义，也必然具有与锁相同的偏序关系。尽管JVM没有对此作出显式的要求。
出处
 

使用
java中对内存屏障的使用在一般的代码中不太容易见到.常见的有两种.

通过 Synchronized关键字包住的代码区域,当线程进入到该区域读取变量信息时,保证读到的是最新的值.这是因为在同步区内对变量的写入操作,在离开同步区时就将当前线程内的数据刷新到内存中,而对数据的读取也不能从缓存读取,只能从内存中读取,保证了数据的读有效性.这就是插入了StoreStore屏障
使用了volatile修饰变量,则对变量的写操作,会插入StoreLoad屏障.
其余的操作,则需要通过Unsafe这个类来执行.