jvm内存模型 与java线程内存模型区别 java jvm 内存模型

一、什么是JMM

内存模型可以理解为在特定的操作协议下，对特定的内存或者高速缓存进行读写访问的过程抽象描述，不同架构下的物理机拥有不一样的内存模型，Java虚拟机是一个实现了跨平台的虚拟系统，因此它也有自己的内存模型，即Java内存模型（Java Memory Model, JMM）。

因此它不是对物理内存的规范，而是在虚拟机基础上进行的规范从而实现平台一致性，以达到Java程序能够“一次编写，到处运行”。

究竟什么是内存模型？

内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节

Java Memory Model(Java内存模型)， 围绕着在并发过程中如何处理可见性、原子性、有序性这三个特性而建立的模型。

二、JMM结构规范

JMM规定了所有的变量都存储在主内存（Main Memory）中。每个线程还有自己的工作内存（Working Memory）,线程的工作内存中保存了该线程使用到的变量的主内存的副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量（volatile变量仍然有工作内存的拷贝，但是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般）。不同的线程之间也无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。

在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

三、主内存和本地内存结构

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。本地内存它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化之后的一个数据存放位置

从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：

1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 然后，线程B到主内存中去读取线程A之前已更新过的共享变量。

下面通过示意图来说明这两个步骤：

如上图所示，本地内存A和B有主内存中共享变量x的副本。假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。

从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。

四、JMM内存操作规则

Java内存模型定义了8种操作来完成【而这8种操作，每一种都是原子操作】：

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

JMM对这八种指令的使用，制定了如下规则：

1、不允许read和load、store和write操作之一单独出现：

• 即不允许一个变量从主存read了但是工作内存不load
• 也不允许从工作内存发起store了但是主存不write

以上两个操作必须按顺序执行，但没有保证必须连续执行：也就是说，read与load之间、store与write之间是可插入其他指令的。

2、不允许一个线程丢弃它的最近的assign操作

• 即变量在工作内存中改变了之后必须把该变化同步回主内存。

3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。

4、一个新的变量只能从主内存中“诞生”

• 不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。

5、一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。

6、如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

7、如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。

8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）。

五、JMM的三个特征

Java内存模型是围绕着并发编程中原子性、可见性、有序性这三个特征来建立的，那我们依次看一下这三个特征：

5.1 原子性（Atomicity）

一个操作不能被打断，要么全部执行完毕，要么不执行。在这点上有点类似于事务操作，要么全部执行成功，要么回退到执行该操作之前的状态。

基本类型数据的访问大都是原子操作，long 和double类型的变量是64位，但是在32位JVM中，32位的JVM会将64位数据的读写操作分为2次32位的读写操作来进行，这就导致了long、double类型的变量在32位虚拟机中是非原子操作，数据有可能会被破坏，也就意味着多个线程在并发访问的时候是线程非安全的。

下面我们来演示这个32位JVM下，对64位long类型的数据的访问的问题：

public class NotAtomicity {
    //静态变量t
    public  static long t = 0;
    //静态变量t的get方法
    public  static long getT() {
        return t;
    }
    //静态变量t的set方法
    public  static void setT(long t) {
        NotAtomicity.t = t;
    }
    //改变变量t的线程
    public static class ChangeT implements Runnable{
        private long to;
        public ChangeT(long to) {
            this.to = to;
        }
        public void run() {
            //不断的将long变量设值到 t中
            while (true) {
                NotAtomicity.setT(to);
                //将当前线程的执行时间片段让出去，以便由线程调度机制重新决定哪个线程可以执行
                Thread.yield();
            }
        }
    }
    //读取变量t的线程，若读取的值和设置的值不一致，说明变量t的数据被破坏了，即线程不安全
    public static class ReadT implements Runnable{

        public void run() {
            //不断的读取NotAtomicity的t的值
            while (true) {
                long tmp = NotAtomicity.getT();
                //比较是否是自己设值的其中一个
                if (tmp != 100L && tmp != 200L && tmp != -300L && tmp != -400L) {
                    //程序若执行到这里，说明long类型变量t，其数据已经被破坏了
                    System.out.println(tmp);
                }
                将当前线程的执行时间片段让出去，以便由线程调度机制重新决定哪个线程可以执行
                Thread.yield();
            }
        }
    }
    public static void main(String[] args) {
        new Thread(new ChangeT(100L)).start();
        new Thread(new ChangeT(200L)).start();
        new Thread(new ChangeT(-300L)).start();
        new Thread(new ChangeT(-400L)).start();
        new Thread(new ReadT()).start();
    }
}

我们创建了4个线程来对long类型的变量t进行赋值，赋值分别为100,200，-300，-400，有一个线程负责读取变量t,如果正常的话，读取到的t的值应该是我们赋值中的一个，但是在32的JVM中（ps: 64位的就别想了），事情会出乎预料。如果程序正常的话，我们控制台不会有任何的输出，可实际上，程序一运行，控制台就输出了下面的信息：
-4294967096
4294966896
-4294967096
-4294967096
4294966896

之所以会出现上面的情况，是因为在32位JVM中，64位的long数据的读和写都不是原子操作，即不具有原子性，并发的时候相互干扰了。

32位的JVM中，要想保证对long、double类型数据的操作的原子性，可以对访问该数据的方法进行同步，就像下面的：

public class Atomicity {
    //静态变量t
    public  static long t = 0;
    //静态变量t的get方法,同步方法
    public synchronized static long getT() {
        return t;
    }
    //静态变量t的set方法，同步方法
    public synchronized static void setT(long t) {
        Atomicity.t = t;
    }
    //改变变量t的线程
    public static class ChangeT implements Runnable{
        private long to;
        public ChangeT(long to) {
            this.to = to;
        }
        public void run() {
            //不断的将long变量设值到 t中
            while (true) {
                Atomicity.setT(to);
                //将当前线程的执行时间片段让出去，以便由线程调度机制重新决定哪个线程可以执行
                Thread.yield();
            }
        }
    }
    //读取变量t的线程，若读取的值和设置的值不一致，说明变量t的数据被破坏了，即线程不安全
    public static class ReadT implements Runnable{

        public void run() {
            //不断的读取NotAtomicity的t的值
            while (true) {
                long tmp = Atomicity.getT();
                //比较是否是自己设值的其中一个
                if (tmp != 100L && tmp != 200L && tmp != -300L && tmp != -400L) {
                    //程序若执行到这里，说明long类型变量t，其数据已经被破坏了
                    System.out.println(tmp);
                }
                将当前线程的执行时间片段让出去，以便由线程调度机制重新决定哪个线程可以执行
                Thread.yield();
            }
        }
    }
    public static void main(String[] args) {
        new Thread(new ChangeT(100L)).start();
        new Thread(new ChangeT(200L)).start();
        new Thread(new ChangeT(-300L)).start();
        new Thread(new ChangeT(-400L)).start();
        new Thread(new ReadT()).start();
    }
}

这样做的话，可以保证对64位数据操作的原子性。

5.2 可见性

一个线程对共享变量做了修改之后，其他的线程立即能够看到（感知到）该变量这种修改（变化）。
Java内存模型是通过将在工作内存中的变量修改后的值同步到主内存，在读取变量前从主内存刷新最新值到工作内存中，这种依赖主内存的方式来实现可见性的。
无论是普通变量还是volatile变量都是如此，区别在于：volatile的特殊规则保证了volatile变量值修改后的新值立刻同步到主内存，每次使用volatile变量前立即从主内存中刷新，因此volatile保证了多线程之间的操作变量的可见性，而普通变量则不能保证这一点。

除了volatile关键字能实现可见性之外，还有synchronized,Lock，final也是可以的。

使用synchronized关键字，在同步方法/同步块开始时（Monitor Enter）,使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在同步方法/同步块结束时(Monitor Exit),会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。

使用Lock接口的最常用的实现ReentrantLock(重入锁)来实现可见性：当我们在方法的开始位置执行lock.lock()方法，这和synchronized开始位置（Monitor Enter）有相同的语义，即使用共享变量时会从主内存中刷新变量值到工作内存中（即从主内存中读取最新值到线程私有的工作内存中），在方法的最后finally块里执行lock.unlock()方法，和synchronized结束位置（Monitor Exit）有相同的语义,即会将工作内存中的变量值同步到主内存中去（即将线程私有的工作内存中的值写入到主内存进行同步）。

final关键字的可见性是指：被final修饰的变量，在构造函数数一旦初始化完成，并且在构造函数中并没有把“this”的引用传递出去（“this”引用逃逸是很危险的，其他的线程很可能通过该引用访问到只“初始化一半”的对象），那么其他线程就可以看到final变量的值。

5.3 有序性

对于一个线程的代码而言，我们总是以为代码的执行是从前往后的，依次执行的。这么说不能说完全不对，在单线程程序里，确实会这样执行；但是在多线程并发时，程序的执行就有可能出现乱序。用一句话可以总结为：在本线程内观察，操作都是有序的；如果在一个线程中观察另外一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行语义（WithIn Thread As-if-Serial Semantics）”,后半句是指“指令重排”现象和“工作内存和主内存同步延迟”现象。

一个最经典的例子就是银行汇款问题，一个银行账户存款100，这时一个人从该账户取10元，同时另一个人向该账户汇10元，那么余额应该还是100。那么此时可能发生这种情况，A线程负责取款，B线程负责汇款，A从主内存读到100，B从主内存读到100，A执行减10操作，并将数据刷新到主内存，这时主内存数据100-10=90，而B内存执行加10操作，并将数据刷新到主内存，最后主内存数据100+10=110，显然这是一个严重的问题，我们要保证A线程和B线程有序执行，先取款后汇款或者先汇款后取款，此为有序性。

Java提供了两个关键字volatile和synchronized来保证多线程之间操作的有序性,volatile关键字本身通过加入内存屏障来禁止指令的重排序，而synchronized关键字通过一个变量在同一时间只允许有一个线程对其进行加锁的规则来实现，

在单线程程序中，不会发生“指令重排”和“工作内存和主内存同步延迟”现象，只在多线程程序中出现。

六、Volatile

Volatile 是 Java 虚拟机提供轻量级的同步机制，有以下性质：

• 保证可见性
• 不保证原子性
• 禁止指令重排

简单的特性，往往配合具体的代码食用更佳👨🍳

6.1 保证可见性

问题： 程序不知道主内存的值已经被修改过了，此时会发生什么情况？

public class Demo2 {
    //private  volatile static  int num  = 0;
    private static  int num  = 0;

    public static int get(){
        return num;
    }

    public static void main(String[] args) {
        new Thread(()->{
            while (get() ==0){
                //System.out.println方法加了synchronized,因此可能造成线程中断，影响本例测试。
                //System.out.println(Thread.currentThread().getName());
            }
        },"A").start();

        //休眠一秒，确保赋值操作在线程启动之后
        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        num = 1;
        System.out.println("num = "+num);
    }
}

此时程序在输出：num = 1

然后进入死循环，原因：在A线程的工作空间中不知num已经发生了变化，即没有对主存内有可见性，仍认为在num == 0为true，所以一直在循环。

解决方法：

使用volatile ：

private volatile static  int num  = 0;

此时程序在输出后立刻停止，由此证明 volatile 的可见性。

也可以用synchronized：

public synchronized static int get(){
        return num;
    }

但是synchronized会影响并发性能。

6.2 不保证原子性

原子性：简单来说就是不可分割，即一个操作或者多个操作。要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

同理，原子性操作：

原子操作可以是一个步骤，也可以是多个操作步骤，但是其顺序不可以被打乱，也不可以被切割而只执行其中的一部分，将整个操作视作一个整体是原子性的核心特征。

反证法：假设volatile 保证原子性：

public class Demo2 {
    // volatile 不保证原子性
    private volatile static int num = 0;

    public static void add() {
        num++;
    }

    public static void main(String[] args) {
        //理论上num结果应该为 20000
        for (int i = 1; i <= 20; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    add();
                }
            },"A").start();
        }
        //先让A线程执行num++操作,等线程执行完毕后再输出
        while (Thread.activeCount() > 2) { // main gc
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + " " + num);
    }
}

理论上num的值应该是2000，但实际上：

main 19209 //总是差点才能到

对于一个非原子性操作的 num++

找到.class文件：javap -c Demo2.class 反编译操作：

解决方法：

给add()方法加上锁，用lock或者synchronized都可以

//synchronized
public synchronized static void add() {
    num++;
}

//lock
private static Lock lock = new ReentrantLock();

public  static void add() {
    lock.lock();
    try {
        num++;
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        lock.unlock();
    }
}

问题又来了，如果不加 lock 和 synchronized ，怎么样保证原子性？

答：使用原子类 <==解决原子性问题

public class Demo2 {
    // volatile 不保证原子性
    //    private volatile static int num = 0;

    // 原子类的 Integer
    private volatile static AtomicInteger num = new AtomicInteger();

    public static void add() {
        num.getAndIncrement();//AtomicInteger + 1 方法， CAS
    }

    public static void main(String[] args) {
        //理论上num结果应该为 20000
        for (int i = 1; i <= 20; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    add();
                }
            }, "A").start();
        }
        //先让A线程执行num++操作
        while (Thread.activeCount() > 2) { // main gc
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + " " + num);
    }
}

多次测试结果都为：

main 20000

反编译结果：

其底层：

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

//在unsafe类里：
public final int getAndAddInt(Object var1, long var2, int var4) {
    int var5;
    do {
        var5 = this.getIntVolatile(var1, var2);
    } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

    return var5;
}

这些类的底层都直接和操作系统挂钩！在内存中修改值！Unsafe类是一个很特殊的存在！

6.3 禁止指令重排

什么是指令重排？

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。

你写的程序，计算机并不是按照你写的那样去执行的。

源代码–>编译器优化的重排–> 指令并行也可能会重排–> 内存系统也会重排—> 执行

处理器在进行指令重排的时候==> 考虑：数据之间的依赖性

int x = 1; // 1
int y = 2; // 2
x = x + 5; // 3
y = x * x; // 4

//我们所期望的：1234 但是可能执行的时候回变成 2134 1324
//可不可能是 4123！ 不可能。

单个线程的情况下，发生指令重排，一般都不会对程序结果有影响，但多线程情况下，则会有影响。
举例：

执行顺序	线程A	线程B
①	x=a	y=b
②	b=1	a=2

正常的结果： x = 0；y = 0；但是可能由于指令重排

执行顺序	线程A	线程B
①	b=1	a=2
②	x=a	y=b

指令重排导致的诡异结果： x = 2；y = 1；
指令重排，应该是概率性问题。

volatile可以避免指令重排：

• 内存屏障
• CPU指令。

作用：

• 保证特定的操作的执行顺序！
• 可以保证某些变量的内存可见性 （利用这些特性volatile实现了可见性）

小结：

Volatile 是可以保持 可见性。不能保证原子性，由于内存屏障，可以保证避免指令重排的现象产生。