JMM - Java 内存模型

JMM定义

JMM 即 Java Memory Model，也叫 Java 内存模型。JMM 就是一种规范，它定义了什么情况开发者不需要去感知计算机的各种重排序，什么情况需要开发者去干涉重排序，以保证程序的执行结果可预测。

JMM的由来

计算机这么多年来整体运行速度不断地提升，除了像CPU时钟频率、内存读写速度等硬件性能不断提升之外，还要归功于计算机科学家对于计算机对于各种指令处理效率的不断优化，包括超标量流水线技术，动态指令调度，猜测执行，多级缓存技术等。在这其中，允许重排序对于计算机运行效率的提升产生了重要的作用，但同时也带来了一些问题。计算机只能确保单线程情况下重排序对于运行结果没有影响，对于多线程就无能为力了。这个时候就需要一个规范来保证开发者既能享受重排序带来的性能的提升又能让复杂情况下的运行结果可控，JMM 就是这样一个规范。JMM 规定了 JVM 必须遵循的一组最小保证，这组保证规定了对变量的操作何时对其他线程可见。换句话说，JMM 对内存可见性作出了一些承诺，在承诺之外，开发者需要自己去处理内存可见性问题。

内存可见性问题

上面提到了内存可见性问题，那么，什么是内存可见性问题。

内存可见性问题的核心是 CPU 的缓存与主内存不一致。

那么，这里就涉及到计算机原理的部分知识，下图是 X86 架构下 CPU 缓存的布局：

image

CPU架构图
从图中可以看出 CPU 有多级缓存，每个核心的一二级缓存数据都是该 CPU 核心私有的，由于有缓存一致性协议（例如 MESI ）的存在，各个核心的缓存之间不会存在不同步的问题。

这里简单讲一下缓存一致性协议 MESI，当各个 CPU 核心都缓存了一个共享变量时，有任何一个核心对它作出了修改都会让其他核心内对应变量的缓存单元失败（这里失效的是整个 CacheLine，不仅仅是变量所占用的区域）并且把修改值同步到主内存。其他核心如果后续要操作这个变量，必须从主内存读，这样就可以保证各个缓存的一致性。

但引入缓存一致性协议会有很大的性能损耗，为了解决这个问题，又进行了各种优化，这其中就有在计算单元和一级缓存之间引入 StoreBuffer 和 LoadBuffer ，如下图所示：

加入各种Buffer的CPU架构图组
StoreBuffer 和 LoadBuffer 的引入，大大提升了计算机性能，但同时也带来了一些问题：各级缓存之间数据是一致的，但 StoreBuffer 和 LoadBuffer 一级缓存之间的数据却是异步的，这里就会存在一致性问题。

当一个缓存中的数据被修改后，会存到 StoreBuffer 中，而 StoreBuffer 不会立即把修改后的数据同步到主内存，这时其他核心在主内存中读取到就是旧数据，也就是说一个数据在一个核心的写操作会出现对其他核心不可见的情况，这就是内存可见性问题。

重排序
上面讲的内存可见性问题其本质就是 CPU 内存重排序，它是重排序的一种。这里讲一下什么是重排序。

重排序分为三种：编译重排序、CPU 指令重排序和 CPU 内存重排序。

• 编译器重排序：对于没有先后依赖的语句，编译器可以重新调整语句的顺序；
• CPU 指令重排序：对于没有先后依赖的指令并行执行；
• CPU 内存重排序：CPU 有自己的缓存，指令的执行顺序与写入主内存的顺序不一定一致。
  编译器重排序对开发者来说是无感知的，我们主要关注的是 CPU 指令重排序和 CPU 内存重排序，这两者都会对运行结果产生影响。

举个例子：假如有 X，Y，a，b 四个共享变量，我们在两个不同的线程分别执行下面的代码：
线程一：

X = 1;
a = Y;

线程二：

Y = 1;
b = X;

这两个线程的执行顺序是不一定的，有可能是顺序执行，也可能是交叉执行，最终结果可能是：

• a = 0, b = 1 (线程一执行 -> 线程二执行)
• b = 0, a = 1 (线程二执行 -> 线程一执行)
• a = 1, b = 1 (两个线程交叉执行)
  上面就是 CPU 指令重排序产生的影响。但实际情况会有第四种结果：
• a = 0, b = 0 （内存重排序）

导致这个结果的原因是两个线程全部或其中一个的写入操作没有同步到主内存中，因此给 a 或 b 赋值时读取到的还是旧值 0，这就是内存可见性问题。

CPU 指令重排序问题我们可以通过锁、CAS 等同步机制来解决，编译器重排序和 CPU 内存重排序都可以通过引入内存屏障来解决，这里主要关注内存屏障在 CPU 重排序的应用。

内存屏障

内存屏障是一个比较底层的概念，它能对重排序作一定的限制，不同的内存屏障对重排序限制不同，一般都是组合使用的。作为 Java 开发者我们知道使用 volatile 关键字修饰的变量不会存在内存可见性问题，它的原理其实就是在对变量的操作前后都加入了两个不同的内存屏障，以保证所有的读写组合都不会发生内存可见性问题。

可以把内存屏障分为四类：

• LoadLoad：禁止读和读的重排序
• StoreStore：禁止写和写的重排序
• LoadStore：禁止读和写的重排序
• StoreLoad：禁止写和读的重排序

JDK 8 开始，Unsafe 类提供了三个内存屏障方法：

public final class Unsafe { 
    // ...
    public native void loadFence(); 
    public native void storeFence(); 
    public native void fullFence(); 
    // ...
}

这三个方法对应的内存屏障如下：

• loadFence = LoadLoad + LoadStore
• storeFence = StoreStore + LoadStore
• fullFence = loadFence + storeFence + StoreLoad

我们平常在开发中一般不会去主动使用内存屏障，而内存屏障所实现的效果可以用 happen-before 来描述。

happen-before

首先来说说什么是 happen-before：它用来描述来个操作之间的内存可见性，如果 A 操作 happen-before 于 B 操作，那么 A 操作的执行结果必须是对 B 操作可见的，这里隐含了一个条件，只有在 A 操作的执行实际发生在 B 操作之前，这个可见性保证才会有效，happen-before 并不会去改变 A 和 B 的执行顺序。

JMM 规范借助 happen-before 可以更好的描述出来。

happen-before 有以下四个基本规则：

• 单线程中的每个操作，happen-before于该线程中任意后续操作。
• 对volatile变量的写，happen-before于后续对这个变量的读。
• 对synchronized的解锁，happen-before于后续对这个锁的加锁。
• 对final变量的写，happen-before于final域对象的读，happen-before于后续对final变量的读。

除了以上四个基础规则之外，happen-before 还具有传递性。传递性是指当 A happen-before 于 B，B happen-before 于 C ，那么操作 A 的结果一定对操作 C 可见。

这四个基本规则再加上 happen-before 的传递性，就构成了 JMM 对开发者的整个承诺。在这个承诺之后的部分，开发者就需要小心处理内存可见性问题。