简介

Java 内存模型（Java Memory Model, JMM）是用来屏蔽各种硬件和操作系统的内存访问差异，实现让Java程序在各种操作系统平台下都能达到一致的访问效果。

工作内存和主内存

Java 内存模型规定了所有的变量都存储在主内存（Main Memory）中，每个线程还有自己的工作内存（Working Memory）, 线程的工作内存保存了该线程使用变量的主内存的副本（这里需要解释一下，如果一个变量 10M 是否会创建变量副本，答案是不会的，但是可能对该字段的某个即将访问的字段创建副本，其实可以理解为是计算机中内存和高速缓存的概念），线程对变量的所有操作都是在工作内存中进行，而不能直接读写主内存中的数据。

不同的线程之间也不能直接访问对方工作内存中的变量，线程之间变量的传递均需要通过主内存完成。线程、工作内存、主内存之间的交互关系如下图所示。

内存间交互

主内存和工作内存之间的交互协议，即一个变量如何从主内存中拷贝到工作内存、如何从工作内存中回写到主内存中的细节。

Java 内存模型中定义了以下 8 种操作：

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

下面是 initFlag 变量在 A、B 线程修改的过程（最后 B线程修改成功）的例子：

如果要把变量从主内存拷贝到工作内存，按顺序执行read load,反之，要把变量从工作内存同步回主内存，也要按顺序执行store和write。以上两个操作必须按顺序，但不必连续，他们之间可以插入其他指令，比如对主内存中变量a,b访问，可以是 read a read b load a load b 。此外，8种基操必须满足一下规则：

read load store write 不能单独出现，从主内存读出，工作内存必须接受，反之亦然
不允许线程丢弃最近的assign操作，就是执行引擎一旦执行，就必须assign再同步回主内存
新变量只能在主内存诞生，不允许工作内存中使用未被初始化(load或assign)的变量，也就是强调了load 和use以及assign和store的不可分割性，出现use store就必须出现load assign
一个变量同一时刻只能被一条线程独占lock，可多次lock。但是要进行相同次数的unlock才能解锁。也就是，lock和unlock一比一才能解锁
lock操作会去清空工作内存中此变量的值，在执行引擎使用该变量前，需要重新执行load或assign操作以初始化变量的值。
同4，unlock和lock是一对一的，不能对没有lock的变量unlcok，也不能拿到lock但没有unlock的变量。也不允许去unlock其他线程lock的变量
一个变量unlock之前必须把此变量同步回主内存中，也就是执行store write

volatile 型变量规则

被 volatile 关键字修饰的变量有两大特点：保证可见性、禁止指令排序优化。

保证可见性

指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。 但是 volatile 不保证原子性，举个例子：

public class VolatileTest {
    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(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }
        //等待所有累加线程都结束
        while (Thread.activeCount() > 1)
            Thread.yield();
        System.out.println(race);
    }
}
复制代码

这段代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果这段代码能够正确并发的话，最后输出的结果应该是200000。

运行结果：

运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字，这是为什么呢？

问题就出现在自增运算 "race++" 之中，我们用Javap反编译这段代码后会得到代码清单，发现只有一行代码的increase() 方法在Class文件中是由4条字节码指令构成的（return指令不是由race++产生的，这条指令可以不计算），从字节码层面上很容易就分析出并发失败的原因了：**当getstatic指令把race的值取到操作栈顶时，volatile关键字保证了race的值在此时是正确的，但是在执行iconst_1、 iadd这些指令的时候，其他线程可能已经把race的值加大了，而在操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存之中。**下面是VolatileTest的字节码：

我们也可以通过-XX:+PrintAssembly 参数输出反汇编来分析会更加严谨。

由于volatile变量只能保证可见性，如果符合以下两条规则才能保证原子性：

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

如果在不符合以下两条规则的运算场景中，我们仍然要通过加锁（使用synchronized或java.util.concurrent中的原子类）来保证原子性。

下面是一个正确的例子，我们只要修改了 start 变量，就可以进入逻辑的执行：

禁止指令排序优化

使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”（Within-Thread As-If-SerialSemantics）。

下面代码是一段标准的DCL单例代码，可以观察加入volatile和未加入volatile关键字时所生成汇编代码的差别。

public class Singleton {
    private volatile static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    public static void main(String[] args) {
        Singleton.getInstance();
    }
}
复制代码

编译后，这段代码对instance变量赋值部分如下所示：

0x01a3de0f：mov$0x3375cdb0，%esi；……beb0cd75 33
；{oop（'Singleton'）}
0x01a3de14：mov%eax，0x150（%esi）；……89865001 0000
0x01a3de1a：shr$0x9，%esi；……c1ee09
0x01a3de1d：movb$0x0，0x1104800（%esi）；……c6860048 100100
0x01a3de24：lock addl$0x0，（%esp）；……f0830424 00
；*putstatic instance
；-
Singleton：getInstance@24
复制代码

通过对比发现，关键变化在于有volatile修饰的变量，赋值后（前面mov%eax，0x150（%esi）这句便是赋值操作）多执行了一个“lock addl ＄0x0，（%esp）”操作，这个操作相当于一个内存屏（Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；但如果有两个或更多CPU访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。这句指令中的“addl ＄0x0，（%esp）”（把ESP寄存器的值加0）显然是一个空操作（采用这个空操作而不是空操作指令nop是因为IA32手册规定lock前缀不允许配合nop指令使用），关键在于lock前缀，查询IA32手册，它的作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化（Invalidate）其Cache，这种操作相当于对Cache中的变量做了一次前面介绍Java内存模式中所说的“store和write”操作。所以通过这样一个空操作，可让前面volatile变量的修改对其他CPU立即可见。

那为何说它禁止指令重排序呢？从硬件架构上讲，指令重排序是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。但并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保障程序能得出正确的执行结果。譬如指令1把地址A中的值加10，指令2把地址A中的值乘以2，指令3把地址B中的值减去3，这时指令1和指令2是有依赖的，它们之间的顺序不能重排——（A+10）2与A2+10显然不相等，但指令3可以重排到指令1、 2之前或者中间，只要保证CPU执行后面依赖到A、 B值的操作时能获取到正确的A和B值即可。所以在本内CPU中，重排序看起来依然是有序的。因此，lockaddl＄0x0，（%esp）指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这样便形成了“指令重排序无法越过内存屏障”的效果。

解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义——它能让我们的代码比使用其他的同步工具更快吗？在某些情况下，volatile的同步机制的性能确实要优于锁（使用synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地认为volatile就会比synchronized快多少。如果让volatile自己与自己比较，那可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁低，我们在volatile与锁之中选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。

long 和 double 变量规则

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

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

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

原子性、可见性、有序性

Java 内存模型的三大特性：原子性、可见性、有序性

原子性(Atomicity)

一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的。

如何保证原子性 ?

通过 synchronized 关键字保证原子性。
通过 Lock 保证原子性。
通过 CAS 保证原子性。

可见性(Visibility)

当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的。

如何保证可见性 ?

通过 volatile 关键字保证可见性。
通过内存屏障保证可见性。
通过 synchronized 关键字保证可见性。
通过 Lock 保证可见性。
通过 final 关键字保证可见性

有序性(Ordering)

即程序执行的顺序按照代码的先后顺序执行。JVM 存在指令重排，所以存在有序性问题。 如何保证有序性?

通过 volatile 关键字保证可见性。
通过内存屏障保证可见性。
通过 synchronized 关键字保证有序性。
通过 Lock 保证有序性。

先行发生原则 (Happes-Before)

“先行发生”（happens-before）的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则解决并发环境下两个操作之间是否可能存在冲突的问题。

概念解释

现在就来看看“先行发生”原则指的是什么。先行发生是Java内存模型中定义的两项操作之间顺序关系，举个例子：

//以下操作在线程A中执行
i=1；
//以下操作在线程B中执行
j=i；
//以下操作在线程C中执行
i=2；
复制代码

假设线程A中的操作“i=1”先行发生于线程B的操作“j=i”，那么可以确定在线程B的操作执行后，变量j的值一定等于1，得出这个结论的依据有两个：

一是根据先行发生原则，“i=1”的结果可以被观察到；
二是线程C还没“登场”，线程A操作结束之后没有其他线程会修改变量i的值。

现在再来考虑线程C，我们依然保持线程A和线程B之间的先行***，而线程C出现在线程A和线程B的操作之间，但是线程C与线程B没有先行***，那j的值会是多少呢？答案是不确定！1和2都有可能，因为线程C对变量i的影响可能会被线程B观察到，也可能不会，这时候线程B就存在读取到过期数据的风险，不具备多线程安全性。

先行***

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

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

先行发生规则

Java语言无须任何同步手段保障就能成立的先行发生规则就只有上面这些了，笔者演示一下如何使用这些规则去判定操作间是否具备顺序性，对于读写共享变量的操作来说，就是线程是否安全，读者还可以从下面这个例子中感受一下“时间上的先后顺序”与“先行发生”之间有什么不同：

private int value=0；
pubilc void setValue（int value）{
    this.value=value；
}
public int getValue（）{
    return value；
}
复制代码

以上显示的是一组再普通不过的getter/setter方法，假设存在线程A和B，线程A先（时间上的先后）调用了“setValue（1）”，然后线程B调用了同一个对象的“getValue（）”，那么线程B收到的返回值是什么？

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

那怎么修复这个问题呢？我们至少有两种比较简单的方案可以选择：要么把getter/setter方法都定义为synchronized方法，这样就可以套用管程锁定规则；要么把value定义为volatile变量，由于setter方法对value的修改不依赖value的原值，满足volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行***。

通过上面的例子，我们可以得出结论：一个操作“时间上的先发生”不代表这个操作会是“先行发生”，那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢？很遗憾，这个推论也是不成立的，一个典型的例子就是多次提到的“指令重排序”，演示例子如下代码所示：

//以下操作在同一个线程中执行
int i=1；
int j=2；
复制代码

以上代码的两条赋值语句在同一个线程之中，根据程序次序规则，“int i=1”的操作先行发生于“int j=2”，但是“int j=2”的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性，因为我们在这条线程之中没有办法感知到这点。上面两个例子综合起来证明了一个结论：时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。

原文链接：https://juejin.cn/post/7092786831905226765

关于Java内存模型，你究竟懂多少？

简介