JVM（7）-Java 内存模型

本文引用自文献：1）《深入理解Java虚拟机》，作者：周志明；
阅读本篇内容前建议先了解计算机的并发相关知识，参考：并发编程—计算机并发编程的基础知识

Java虚拟机规范中试图定义一种Java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一直的内存访问效果。在此之前，主流程序语言（如C/C++等）直接使用物理硬件和操作系统的内存模型，因此，会由于不同平台上内存模型的差异，有可能导致程序在一套平台上并发完全正常，而在另外一套平台上并发访问经常出错，因此在某些场景就必须针对不同的平台来编写程序。

定义Java内存模型并非一件容易的事，这个模型必须定义得足够严谨，才能让Java的并发内存访问操作不会产生问题；但也必须定义地足够宽松，才能使得虚拟机的实现有足够的自由空间去利用硬件的各种特性来获取更好的执行速度。经过长时间的验证和修补，JDK1.5（实现了JSR-133）发布之后，Java内存模型已经成熟和完善起来了，本篇内容也即是基于这个模型。

主内存与工作内存

Java内存模型的主要目的是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。注意：此处的变量是指实例字段、静态字段和构成数组对象的元素，并不包括局部变量与方法参数，因为它们是线程私有的，不会被共享，所以不会存在并发问题。

Java内存模型中规定了所有的变量都存储在主内存（Main Memory）中，每条线程还有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用到的变量的主内存的拷贝副本，线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。线程、主内存和工作内存的交互关系如下图所示：

上面这段是Java内存模型的基础规则，有几个点再补充说明一下。

首先是主内存和工作内存的概念。这里的主内存并不是指计算机的主内存，它只是Java虚拟机内存的一部分，但是两者也可以互相类比，主内存可以看作是对应于计算机的主内存；工作内存则可以看作是JVM中对高速缓存和寄存器的一个抽象，在《Concurrent Programming in Java: Design Principles and Patterns, Second Edition》§2.2.7 这篇文章中有说明，原文是：Every thread is defined to have a working memory (an abstraction of caches and registers) in which to store values。
另外，主内存、工作内存的概念与 JVM 中的堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的。如果两者一定要勉强对应起来，那从变量、主内存、工作内存的定义来看，主内存主要对应与Java堆中的对象的实例数据部分，而工作内存则对应与虚拟机站中的部分区域。

其次是“拷贝副本”的问题，假设线程中访问一个10MB的对象，也会把这个10MB的内存复制一份到工作内存中吗？事实上并不会如此，拷贝的只会是这个对象的引用，或者是这个对象中线程要访问的字段，并不会把整个对象拷贝一次。

第三个是volatile修饰的字段也会拷贝到工作内存吗？是的！根据Java虚拟机规范，volatile变量依然会拷贝到工作内存，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般。

内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的：

lock（锁定）：作用于主内存中的变量，它把一个变量标识为一条线程独占的状态。
unlock（解锁）：作用于主内存中的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
read（读取）：作用于主内存中的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存中的变量，它把一个从执行引擎接收到的值赋值给工作内存中的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存中的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
write（写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量值放入主内存的变量中。

如果要把一个变量从主内存中复制到工作内存，那就需要顺序地执行read和load操作；如果要把变量从工作内存同步回主内存，就要顺序地执行store和write操作。
注意，Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。

除此之外，Java内存模型还规定了在执行上述8种基本操作时，必须满足如下规则：

不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起会写了但主内存不接受的情况出现。
不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
一个新的变量只能从主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。换句话说，就是对于i个变量实施user、store操作之前，必须先执行过了assign和load操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
如果一个变量事先没有被lock操作锁定，那就不允许对它进行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

对于long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、use、assign、store、write这8个操作都具有原子性。但是对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被volatile修饰的64位数据读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的read、load、store、write这4个操作的原子性。这就是所谓的long和double的非原子协定。

如果有多个线程共享一个并未被volatile修饰的long或double类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。

不过这种读取到“半个变量”的情况非常罕见（目前商用的Java虚拟机中不会出现），因为Java内存模型虽然允许虚拟机不把long和double类型变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待，因为我们再编写代码时无需把long和double类型变量专门声明为volatile。

原子性、可见性和有序性

回顾Java内存模型的规范与操作，可以说Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的。

原子性

原子性操作是指：不可被中断的一个操作，一旦执行则整个操作过程将会一次性全部执行完成，不会停留在中间状态。由Java内存模型来直接保证的原子性变量操作包括read、load、use、assign、store、write，我们可以认为基本数据类型的访问读写是具备原子性的（无须过度在意long和double类型的非原子性协定）。

如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java 内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式的使用这两个操作，这两个字节码指令反映到java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

可见性

可见性是指：当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性。对于volatile关键字修饰的变量，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因为，volatile可以保证多线程操作时变量的可见性，而普通变量不能保证这一点。

比如下面这段代码：

int i = 0;

//线程1执行的代码
i = 10;

//线程2执行的代码
j = i;

如果i = 10这条语句由线程1执行，当线程1把i的初始值加载到它的工作内存中，然后赋值为10，但是线程1将工作内存中赋好的值再刷新到主存中的时间是不确定的。如果线程1还没有刷新的主存中，而此时线程2执行j = i，它会先去主存读取i的值并加载到它的工作内存中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是10。这就产生了可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

除了volatile之外，java中还有2个关键字能实现可见性，即synchronized和final（final修饰的变量，线程安全级别最高）。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store，write操作）”这条规则获得；而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那么在其他线程中就能看到final字段的值。例如下面代码中的i和j都具备可见性，它们无需同步就能被其他线程正确地访问。

public static final int i;
public final int j;

static {
    i = 0;
    
    //do something
}

{
    //变量j也可以在构造函数中初始化
    j = 1;

    //do something
}

有序性

Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有操作都是有序的；如果在一个线程中观察另一个线程，所有操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句指的是“指令重排序”现象和“工作内存与主内存同步延迟”现象。

Java语义提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获取的。这个规则决定了持有同一个锁的两个同步块只能串行的进入。

happens-before原则

如果Java内存模型中所有的有序性都仅仅依靠volatile和synchronized来完成，那么有一些操作将变得很繁琐，但是我们在编写Java程序时确没有感觉到这一点，这是因为Java语言中有一个“先行发生”（happens-before）的原则。这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。

所谓先行发生原则是指Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，那么操作A产生的影响能够被操作b观察到，”影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。

下面是Java内存模型中存在的一些“天然的”先行发生关系，这些先行发生关系无需任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系并不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保证，虚拟机可以对它们随意地进行重排序。

程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支，循环等。
管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而“后面是指时间上的先后顺序”。
Volatile变量规则：对于一个volatile变量的写操作先行发生于对这个变量的写操作，这里的“后面”同样是指时间上的先后顺序。
线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作。
线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测。
线程中断规则：对线程的interrupt()方法的调用先行发生于被中断线程的代码检测到中断时间的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
对象终结规则：一个对象的初始化完成先行发生于它的finalize()方法的开始。
传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那么就可以得出操作A先行发生于操作C得结论。

Java语言无须任何同步手段保障就能成立的先行发生规则就只有上面这些了，下面演示一下如何使用这些规则去判定操作间是否具备顺序性，对于读写共享变量的操作来说，就是判断线程是否安全。代码如下：

private int i = 0;

public void setI(int i) {
    this.i = i;
}

public int getI() {
    return i;
}

这是很普通的一组getter/setter方法，假设A线程先调用了setI(1)，B线程再调用了同一个对象的getI()，那么B线程的返回值是什么？

依次分析一下先行发生原则中的各项规则。由于两个方法分别由两个线程分别调用，因此程序次序规则这里不适用；由于没有同步块，所以也就没有unlock和lock，因此管程锁定规则这里不适用；i没有被关键字volatile修饰，因此volatile变量规则这里不适用；后面的启动、终止、中断、对象终结也和这里完全没有关系，因此也都不适用。因为没有一个实用的先行发生规则，所以最后一条传递性也无从谈起，因此传递性也不适用。由于所有先行发生原则都不适用，因此尽管线程A的setI(1)操作在时间上先发生，但无法确定线程B的getI()的返回结果，换句话说，这里面的操作不是线程安全的。

那如何修复这个问题？至少有两种比较简单的办法：

setter/getter都定义成synchronized的，这样可以套用管程锁定规则
i定义为volatile变量，由于setter方法对i的修改不依赖于i的原值，满足volatile关键字的使用场景，这样可以套用volatile变量规则

happens-before在jdk中的应用分析

下面用happens-before规则再分析两个例子：
Java的api文档中对于java.util.concurrent包下的类有如下说明：

The methods of all classes in java.util.concurrent and its subpackages extend these guarantees to higher-level synchronization. In particular:

Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.

Actions in a thread prior to the submission of a Runnable to an Executor happen-before its execution begins. Similarly for Callables submitted to an ExecutorService.

Actions taken by the asynchronous computation represented by a Future happen-before actions subsequent to the retrieval of the result via Future.get() in another thread.

Actions prior to “releasing” synchronizer methods such as Lock.unlock, Semaphore.release, and CountDownLatch.countDown happen-before actions subsequent to a successful “acquiring” method such as Lock.lock, Semaphore.acquire, Condition.await, and CountDownLatch.await on the same synchronizer object in another thread.

For each pair of threads that successfully exchange objects via an Exchanger, actions prior to the exchange() in each thread happen-before those subsequent to the corresponding exchange() in another thread.

Actions prior to calling CyclicBarrier.await and Phaser.awaitAdvance (as well as its variants) happen-before actions performed by the barrier action, and actions performed by the barrier action happen-before actions subsequent to a successful return from the corresponding await in other threads.

此处使用CopyOnWriteArrayList分析一下第一条：Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.（放入一个元素到并发集合要发生于从并发集合中取元素之前）。

CopyOnWriteArrayList的set方法源码：

/**
 * Replaces the element at the specified position in this list with the
 * specified element.
 *
 * @throws IndexOutOfBoundsException {@inheritDoc}
 */
public E set(int index, E element) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        E oldValue = get(elements, index);

        if (oldValue != element) {
            int len = elements.length;
            Object[] newElements = Arrays.copyOf(elements, len);
            newElements[index] = element;
            setArray(newElements);
        } else {
            // Not quite a no-op; ensures volatile write semantics
            setArray(elements);
        }
        return oldValue;
    } finally {
        lock.unlock();
    }
}

在上面else调用了setArray(elements)方法：

1
2
3

final void setArray(Object[] a) {
    array = a;
}

一个简单的赋值，array是volatile类型。elements是从getArray()方法取过来的，getArray()实现如下：

1
2
3

final Object[] getArray() {
    return array;
}

也很简单，直接返回array。取得array，又重新赋值给array，为什么要这样做呢？setArray(elements)上有条简单的注释，但可能不是太容易明白。正如前文提到的那条javadoc上的规定，放入一个元素到并发集合与从并发集合中取元素之间要有hb关系。set是放入，get是取，怎么才能使得set与get之间有hb关系，set方法的最后有unlock操作，如果get里有对这个锁的lock操作，那么就好满足了，但是get并没有加锁：

1
2
3

public E get(int index) {
    return (E)(getArray()[index]);
}

但是get里调用了getArray，getArray里有读volatile的操作，只需要set走任意代码路径都能遇到写volatile操作就能满足条件了，这里主要就是if…else…分支，if里有个setArray操作，如果只是从单线程角度来说，else里的setArray(elements)是没有必要的，但是为了使得走else这个代码路径时也有写volatile变量操作，就需要加一个setArray(elements)调用。