深入理解JMM(Java内存模型)

一、什么是JMM?

Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的一组规则或者规范。通过这些规则、规范定义了程序中各个变量的访问方式。jvm运行的程序的实体是线程，而每个线程运行时，都会创建一个工作内存（也叫栈空间），来保存线程所有的私有变量。而JMM内存模型规范中规定所有的变量都存储在主内存中，而主内存中的变量是所有的线程都可以共享的，而对主内存中的变量进行操作时，必须在线程的工作内存进行操作，首先将主内存的变量copy到工作内存，进行操作后，再将变量刷回到主内存中。所有线程只有通过主内存来进行通信。

二、JMM与JVM

JMM与JVM是两个不同的概念。JMM规定的是一个规范，通过规范定义了程序中各个变量的访问方式。JMM围绕着原子性、有序性、可见性三点展开。如果非要说有关系，就是JMM、JVM都一个私有、共有的内存区域。

JMM内存模型交互图

主内存

所有线程创建的实例对象都存放在内存中，不管该实例对象是成员变量，还是局部变量，类信息、常量、静态变量都是放在主内存中，属于所有线程共享区域，所以存在线程之间安全问题。

线程不安全

工作内存

主要是存储局部变量（方法内部的变量，存储着主内存中变量的副本），每个线程只能在自己的工作内存中操作变量副本，对其他线程是不可见的。就算两个线程同时执行同一段代码，也是都在自己的工作内存中对变量进行操作。由于线程的工作内存是私有，所以线程之间是不可见的，同时也是线程安全。

线程安全

根据JVM的虚拟机规范以及JMM内存模型规则，对于一个实例对象的成员方法，方法中的所有基本类型变量都会储存在工作内存中的栈帧中，如果变量时引用类型，那么该实例的引用变量储存在工作内存中的栈帧中，而对象的实例会存储在主内存中（共享区域堆中）。至于static变量以及类本身的信息将会存储主内存中。需要注意的是实例对象存储在主内存中，是可以被多个线程共享的，多个线程访问时，也是从主内存copy一份到工作内存中，在进行操作，最后刷新回主内存。

模型如下图所示：

三、Java内存模型与硬件内存架构的关系

多线程的执行最终是映射到硬件层面，通过硬件上的处理器进行执行，但java内存模型跟硬件内存架构并不完全一致。对于硬件内存架构来说，只有寄存器、缓存行、主内存的概念，并没有工作内存（私有内存区域）、主内存（堆内存）之分。也就是说JMM的内存划分对硬件内存架构并没有什么影响，因为JMM是一种抽象的概念，是一种规范，并不实际存在。对于硬件内存来说，不管是工作内存，还是主内存，都是储存在寄存器、缓存行、主内存中，JMM与硬件内存架构是一种相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。（注意对于JVM内存区域划分一样）。

交互图：

四、JMM存在的必要性

由于JVM运行时的实体是线程，每一个线程运行时都会创建一个工作内存，作为线程的私有空间，每个线程操作变量都在自己的工作内存，从主内存copy一份数据到工作内存，在工作内存中进行操作后，再将其刷新回主内存。如果是在多线程的情况下，则会出现线程安全问题。因此JMM规范规定了如下八种操作来完成数据的操作

数据同步八大原子操作

（1）lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态
（2）unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
（3）read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
（4）load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
（5）use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
（6）assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量
（7）store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作
（8）write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

如果一个变量从主内存中复制到工作内存中，就需要按顺序的执行read、load指令，如果是工作内存刷新到主内存则需要按顺序的执行store、write操作。但JMM只保证了顺序执行，并没有保证连续执行。

五、同步规则分析

不允许线程无原因的将变量从工作内存写回主内存（没有经过任何的assign）。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量（load或者assign）的变量，就是对一个变量进行use和store操作之前，必须先自行load与assign操作。
一个变量在同一时刻只能被一个线程lock，同一个线程能多次lock，必须对应的多次unlock，lock与unlock必须成对的出现。
如果对一个变量执行lock操作，将会清除工作内存中此变量的值，在执行引擎使用这个变量时，必须重新load、assign操作。
如果一个线程对一个变量没有进行lock操作，则不允许unlock，也不允许对其他线程进行unlock。
对一个变量进行unlock时，必须先将变量刷新到主内存。

六、可见性，原子性与有序性

原子性

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程给打断。

在java中，对基本的数据类型的操作都是原子性的操作，但是要注意的是对于32位系统的操作对于long、double类型的并不是原子性操作（对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作）。因为对于32位的操作系统来说，每次读写都是32位，而doubel、long则是64位存储单位。就会导致一个线程操作完前面32位后，另一个线程刚好读到后面的32位，这样一来一个64位被两个线程分别读取。

可见性

可见性指的是当一个共享变量被一个线程修改后，其他线程是否能够立即感知到。对于串行执行的程序是不存在可见性，当一个线程修改了共享变量后，后续的线程都能感知到共享变量的变化，也能读取到最新的值，所以对于串行程序来讲是不存在可见性问题。

对于多线程程序，就不一定了，前面分析过对于共享变量的操作，线程都是将主内存的变量copy到工作内存进行操作后，在赋值到主内存中。这样就会导致，一个线程改了之后还未回写到主内存，其余线程就无法感知到变量的更新，线程之间的工作内存是不可见的。另外指令重排序以及编译器优化也会导致可见性的问题。

有序性

有序性是指对于单线程的代码，我们总是认为程序是按照代码的顺序进行执行，对于单线程的场景这样理解是没有问题，但是在多线程情况下，程序就会可能发生乱序的情况，编译器编译成机器码指令后，指令可能会被重排序，重排序的指令并不能保证与没有排序前的保持一致。

在java程序中，倘若在本线程内，所有的操作都可视为有序性，在多线程环境下，一个线程观察另外一个线程，都视为无顺序可言。

七、JMM如何解决原子性&可见性&有序性

原子性问题

除了jvm自身提供的对基本类型的原子性操作以外，可以通过synchronized和Lock实现原子性。synchronized与lock在同一时刻始终只会存在一个线程访问对应的代码块。

可见性问题

volatile关键字保证了可见性。当一个共享变量被volatile修饰时，它会保证共享变量修改的值立即被其他线程可见，即修改的值立即刷新到主内存，当其它线程去需要读取变量时，从主内存中读取。synchronized和Lock也保证了可见性。因为同一时刻只有一个线程能访问同步代码块，所以是能保证可见性。

有序性问题

volatile关键字保证了有序性，synchronized和Lock也保证了有序性（因为同一时刻只允许一个线程访问同步代码块，自然保证了线程之间在同步代码块的有序执行）。

JMM内存模型：每个线程都有自己的工作内存。线程对变量的操作只能在工作内存中进行操作，并且线程之前的工作内存是不可见的。java内粗模型具备一定的先天有序性，happens-before 原则。如果两个操作无法推断出happens-before 原则，则无法保证程序的有序性。虚拟机可以随意的将它们进行排序。

指令重排：即只要程序的最终结果与顺序执行的结果保持一致，则虚拟机就可以进行排序，此过程就叫指令重排序，为啥需要指令重排序？jvm根据处理器特性（cpu多级缓存、多核处理器等）适当的对机器指令进行排序，使机器指令能更符合CPU的执行特性，最大的限度发挥机器性能。

下图为从源码到最终执行的指令序列示意图：

as-if-serial语义

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

happens-before 原则

只靠sychronized和volatile关键字来保证原子性、可见性以及有序性，那么编写并发程序可能会显得十分麻烦，幸运的是，从JDK 5开始，Java使用新的JSR-133内存模型，提供了happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数据是否存在竞争、线程是否安全的依据，happens-before 原则内容如下：

程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行。
锁规则解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。
volatile规则 volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能够看到该变量的最新值。
线程启动规则线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B可见
传递性 A先于B ，B先于C 那么A必然先于C
线程终止规则线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。
线程中断规则对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。
对象终结规则对象的构造函数执行，结束先于finalize()方法

八、volatile内存语义

volatile是java虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用

保证被volatile修饰的共享变量对所有的线程可见的，也就是当一个线程修改一个被volatile修饰的共享变量，能立即刷新到主内存，其他线程能及时感知。
禁止指令重排序

volatile的可见性

关于volatile可见性的问题，我们必须意识到只要被volatile修饰的变量，对其操作，对所有的变量都是立即可见的

示例：

修改了volatile修饰的共享变量，其它线程能立即感知

public class VolatileVisibilitySample {
    volatile boolean initFlag = false;

    public void save () {
        this.initFlag = true;
        String threadName = Thread.currentThread().getName();
        System.out.println("线程：" + threadName + ":修改了共享变量initFlag");
    }

    public void load () {
        String threadName = Thread.currentThread().getName();
        while (!initFlag) {
            // 此处死循环，等待initFlag的变更
            System.out.println("线程：" + threadName + "：等待initFlag变量的变更");
        }
        System.out.println("线程：" + threadName+ "：感知到initFlag变量的变更");
    }

    public static void main(String[] args) throws InterruptedException {
        VolatileVisibilitySample sample = new VolatileVisibilitySample();
        Thread thread_a = new Thread(() -> {
            sample.save();
        }, "thread A");

        Thread thread_b = new Thread(() -> {
            sample.load();
        }, "thread B");

        thread_b.start();;
        Thread.sleep(10);
        thread_a.start();
    }
}

volatile无法保证原子性

public static volatile int i = 0;
    public void add () {
        i ++;
    }

在并发情况下，i ++ 操作是不具备原子性的，此操作分两步，首先读取i值，最后在将i值进行操作后，在写回。如果其他线程在此线程读取i旧值与写回新值之间读取了i值，则线程之间看到的值就是同一个值，所以就会导致利用相同的值进行+1操作，导致数据安全问题。

volatile禁止重排优化

volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象，关于指令重排优化前面已详细分析过，这里主要简单说明一下volatile是如何实现禁止指令重排优化的。先了解一个概念，内存屏障(Memory Barrier）。

硬件层的内存屏障

Intel硬件提供了一系列的内存屏障，主要有：
1. lfence，是一种Load Barrier 读屏障
2. sfence, 是一种Store Barrier 写屏障
3. mfence, 是一种全能型的屏障，具备ifence和sfence的能力
4. Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG等指令。

不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。 JVM中提供了四类内存屏障指令：

内存屏障，又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执行顺序，二是保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）。由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。总之，volatile变量正是通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。下面看一个非常典型的禁止重排优化的例子DCL，如下：

public class DoubleCheckLock {
    private volatile static DoubleCheckLock instance;
    private DoubleCheckLock(){}
    public static DoubleCheckLock getInstance(){
        //第一次检测
        if (instance==null){
            //同步
            synchronized (DoubleCheckLock.class){
                if (instance == null){
                    //多线程环境下可能会出现问题的地方
                    instance = new  DoubleCheckLock();
                }
            }
        }
        return instance;
    }
}

上述代码一个经典的单例的双重检测的代码，这段代码在单线程环境下并没有什么问题，但如果在多线程环境下就可以出现线程安全问题。原因在于某一个线程执行到第一次检测，读取到的instance不为null时，instance的引用对象可能没有完成初始化。

因为instance = new DoubleCheckLock();可以分为以下3步完成(伪代码)

memory = allocate();//1.分配对象内存空间
instance(memory);//2.初始化对象
instance = memory;//3.设置instance指向刚分配的内存地址，此时instance！=null

由于步骤1和步骤2间可能会重排序，如下：

memory=allocate();//1.分配对象内存空间
instance=memory;//3.设置instance指向刚分配的内存地址，此时instance！=null，但是对象还没有初始化完成！
instance(memory);//2.初始化对象

由于步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的。但是指令重排只会保证串行语义的执行的一致性(单线程)，但并不会关心多线程间的语义一致性。所以当一条线程访问instance不为null时，由于instance实例未必已初始化完成，也就造成了线程安全问题。那么该如何解决呢，很简单，我们使用volatile禁止instance变量被执行指令重排优化即可。

 //禁止指令重排优化
private volatile static DoubleCheckLock instance;

volatile内存语义的实现

前面提到过重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。

下图是JMM针对编译器制定的volatile重排序规则表。

举例来说，第二行最后一个单元格的意思是：在程序中，当第一个操作为普通变量的读或写时，如果第二个操作为volatile写，则编译器不能重排序这两个操作。

从上图可以看出：

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前的操作不会被编译器重排序到volatile写之后。
当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
当第一个操作是volatile写，第二个操作是volatile读或写时，不能重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略。

·在每个volatile写操作的前面插入一个StoreStore屏障。
·在每个volatile写操作的后面插入一个StoreLoad屏障。
·在每个volatile读操作的后面插入一个LoadLoad屏障。
·在每个volatile读操作的后面插入一个LoadStore屏障。

上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。

下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图

上图中StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存。

这里比较有意思的是，volatile写后面的StoreLoad屏障。此屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile写的后面是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即return）。为了保证能正确实现volatile的内存语义，JMM在采取了保守策略：在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑，JMM最终选择了在每个 volatile写的后面插入一个StoreLoad屏障。因为volatile写-读内存语义的常见使用模式是：一个写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM 在实现上的一个特点：首先确保正确性，然后再去追求执行效率。

下图是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图

上图中LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。

上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。下面通过具体的示例

代码进行说明。

class VolatileBarrierExample {
       int a;
       volatile int v1 = 1;
       volatile int v2 = 2;
       void readAndWrite() {
           int i = v1;　　    // 第一个volatile读
           int j = v2;    　  // 第二个volatile读
           a = i + j;         // 普通写
           v1 = i + 1;     　 // 第一个volatile写
          v2 = j * 2;    　  // 第二个 volatile写
       }
}

针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化。

注意，最后的StoreLoad屏障不能省略。因为第二个volatile写之后，方法立即return。此时编译器可能无法准确断定后面是否会有volatile读或写，为了安全起见，编译器通常会在这里插入一个StoreLoad屏障。

上面的优化针对任意处理器平台，由于不同的处理器有不同“松紧度”的处理器内存模型，内存屏障的插入还可以根据具体的处理器内存模型继续优化。以X86处理器为例，图3-21 中除最后的StoreLoad屏障外，其他的屏障都会被省略。

前面保守策略下的volatile读和写，在X86处理器平台可以优化成如下图所示。前文提到过，X86处理器仅会对写-读操作做重排序。X86不会对读-读、读-写和写-写操作做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。在X86中，JMM仅需在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存语义。这意味着在 X86处理器中，volatile写的开销比volatile读的开销会大很多（因为执行StoreLoad屏障开销会比较大）。