深入理解JVM（③）学习Java的内存模型

前言

Java内存模型（Java Memory Model）用来屏蔽各种硬件和操作系统的内存访问差异，这使得Java能够变得非常灵活而不用考虑各系统间的兼容性等问题。定义Java内存模型并非一件容易的事情，从Java出生开始经过长时间的验证和修补，直至JDK5发布后Java内存模型才终于成熟、完善起来了。

主内存与工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。

Java内存模型规定了所有变量都存储在主内存（Main Memory）中（此处的内存为Java虚拟机内存的一部分）。每条线程还有自己的工作内存（Working Memory）,线程的工作内存中保存了被该线程使用的变量内存副本，线程对变量的所有操作都必须在工作内存中进行，也不能直接读写主内存中数据。不同的线程之间变量值的传递均需要通过主内存来完成。

线程、主内存、工作内存三者的交互关系如下图。

内存间交互操作

对于主内存和工作内存之间具体的交互协议，Java内存模型中定义了以下8中操作拉完成。

Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

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

如果想要把一个变量从主内存复制到工作内存，那就要按顺序执行read和load操作，如果要把变量从工作内存同步回主内存，就要按顺执行store和write操作。

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

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

上面的8中基本操作，以及这些规则限定了Java程序中哪些内存访问操作在并发下是安全的。虽然繁琐但很严谨，大致操作也可以简化的描述为read、write、lock、unlock四种。我们只需要理解Java内存模型的定义即可。

对于volatile型变量的特殊规则

关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制，但是它并不容易被正确、完整地理解，Java内存模型为volatile专门定义了一些特殊的访问规则。

当一个变量被定义为volatile之后，它将具备两项特性：

第一项是保证此变量对所有线程的“可见性”，可见性是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。

关于volatile变量的可见性，虽然volatile变量对所有线程立即可见，但是基于volatile变量的所有的写操作都能立刻反映到其他线程中的。这句话理论上来说没毛病，但是volatile变量在运算过程中也是存在不一致的情况，因为在Java里面的运算操作符并非原子操作，这导致volatile变量的运算在并发下一样是不安全的。

例如：

/**
 * @author jiomer
 * @date Create in 2020
 * @description volatile变量自增运算测试
 */
public class VolatileOneTest {

    public static volatile int race = 0;

    public static void increase(){
        race++;
    }

    private static final int THREADS_COUNT = 20;

    public static void main(String[] args) {

        Thread[] threads = new Thread[THREADS_COUNT];

        for (int i = 0;i<THREADS_COUNT;i++){

            threads[i] = new Thread(() -> {
                for(int i1 = 0; i1 <10000; i1++){
                    increase();
                }
            });

            threads[i].start();
        }

        while (Thread.activeCount() > 2){
            Thread.yield();
        }

        System.out.println(race);

    }

}

上述代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果能够正确并发的话，运行结果应为20000，但运行结果并不正确，并且每次输出结果都小于20000，且都不相同。

由于volatile变量只能保证可见性，在不符合以下两条规则的运行场景中，我们仍然要通过加锁（synchronized、java.util.concurent中的锁或原子类）来保证原子性：

• 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
• 变量不需要与其他的状态变量共同参与不变约束。

volatile变量的第二项特性是：禁止指令重排序优化。普通的变量金辉保证在该方法的执行过程中所有依赖复制结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

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

上面在介绍Java内存模型的内存交互操作时，介绍了8种操作并明确都是具有原子性的。

但是对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机自行选择是否要保证64位数据类型的load、store、read、和write这四个操作的原子性，这就是所谓的“long 和 double的非原子协定”。

从JDK9开始，HotSpot增加了一个实验性的参数-XX:+AlwaysAtomicAccesses 来约束虚拟机堆所有数据类型进行原子性的访问。另外由于现代中央处理器中一般都包含专门用于处理浮点数据的浮点运算器，所以在实际开发中，除非该数据有明确可知的线程竞争，否则一般不用刻意的把long和double类型的变量声明为volatile。

原子性、可见性、有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的。

原子性

由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write这六个，我们大致可以认为，基本数据类型的访问、读写都是具备原子性的。

如果需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，这两个操作更高层次的字节码指令是monitorenter和monitorexit来隐式地使用这两个操作。这两个操作反应到Java代码中就是synchronized关键字，所以synchronized代码块之间的操作也具备原子性。

可见性

可见性就是指当一个线程修改了共享变量值时，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量这种依赖主内存作为传递媒介的方式来实现可见性，无论是普通变量还是volatile变量都是如此。区别就在于volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

除了volatile之外，Java还有两个关键字能实现可见性，他们是synchronized和final。synchronized的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）”这条规则获得的。

final关键字的可见性是指：被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有吧“this”的引用传递出去，那么在其他线程中就能看见final字段值。

有序性

Java程序中的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。

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

先行发生原则（Happens-Before）

Java语言中有一个“先行发生”（Happens-Before）的原则。这个原则非常重要，它是判断数据是否存在竞争，线程是否安全的非常有用的手段。

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

下面几项规则是Java内存模型中“天然的”先行发生关系，可以直接在代码中使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来，则它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

• 程序次序规则：在一个线程内，安装控制流顺序，书写在前面的操作先行发生于书写在后面的操作。（这里说的是控制流顺序，不是程序代码顺序，因为要考虑分支、循环等）
• 管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。
• volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后。
• 线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作。
• 线程终止规则：线程中所有操作都先行发生于对此线程的终止检测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行。
• 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件发生，可以通过Thread::interrupted()方法检测到是否有中断发生。
• 对象终结规则：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法开始。
• 传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

举个例子说明如何判断操作间是否具备顺序性，对于读写共享变量的操作来说，就是线程是否安全。

public class HappensBeforeTest {

    private int item = 1;

    public int getItem() {
        return item;
    }

    public void setItem(int item) {
        this.item = item;
    }
}

上面的代码，假设线程A（时间上的先后）先调用了setItem(2)，然后线程B调用了同一个对象的getItem()。

先分析一下，由于两个方法不在一个线程中，所以程序次序规则不适用；没有同步块，所以管程锁定规则也不适用；item没有被volatile关键字修饰，所以volatile变量规则不适用；后面的线程启动、终止、中断规则和对象终结规则也和这没关系。因为之前也没有一个适用的先行发生规则，所以也没有传递性规则；

所以我们判定，尽管线程A操作时间上先于线程B，但是无法确定线程B中getItem()方法的返回结果，也就是这里面的操作不是线程安全的。

修复方式有多种，例如把getter/setter方法都加上synchronized，这样符合管程锁定规则；要么把item设置成volatile变量；要么等setter方法执行完成后再指向getter方法，符合程序次序规则。

既然一个操作在“时间上的先发生”不代表这个操作会是“先行发生”。那么一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先行发生”呢？

还是举例说明吧

	// 以下操作在同一个线程中执行
    int item = 1;

    int value = 2;

根据程序次序规则，int item = 1;的操作先行发生于int value = 2;，但是int value = 2;的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性。

所以经过上面两个论证，得出时间先后顺序与先行发生原则之间基本没有因果关系，在衡量是否线程安全时，一切必须以先行发生原则为准。