Java中JMM内存模型与Volatile关键字

最新推荐文章于 2021-04-09 16:39:31 发布

Deeeelete

最新推荐文章于 2021-04-09 16:39:31 发布

阅读量272

点赞数

分类专栏： java相关文章标签： java

本文链接：https://blog.csdn.net/deeeelete/article/details/107433689

版权

java相关专栏收录该内容

39 篇文章 0 订阅

订阅专栏

一：JMM

Java Memory Model，简称JMM，即Java内存模型，但JMM不同于JVM有着堆栈这样详实的块区划分，JMM虽然叫模型，可本质上只是一种强调数据（通常指共享变量）读写的规范，是一种抽象的概念。

那JMM这种规范是干什么的？这里就要提一个东西，那就是线程，线程是程序的经脉，而JMM则是跟线程息息相关的，倘若说没有JMM这种线程的约束规范，那线程里的变量就会被乱用乱丢，然后各种横七八竖的访问，内存里一片狼藉。因此，从程序执行效率的角度上来讲，JMM规范的存在是必要的。

而这种规范展开来详细说，就要引申出JMM的八大指令，指令是JMM底层原子级不可分的操作。

read（读取）：从主内存读取数据
load（载入）：将主内存读取到的数据写入工作内存中
user（使用）：从工作内存读取数据来计算
assign（赋值）：将计算好的值重新赋值到工作内存中
store（存储）：将工作内存数据写入主内存
write（写入）：将store过去的变量值赋值给主内存中的变量
lock（锁定）：将主内存变量加锁，标识为线程独占状态
unlock（解锁）：将主内存变量解锁，解锁后其他线程可以锁定该变量

线程工作详情
以及与八种指令的相关规则：

不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须 write
不允许线程丢弃他近的assign操作，即工作变量的数据改变了之后，必须告知主存
不允许一个线程将没有assign的数据从工作内存同步回主内存
一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。
一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
对一个变量进行unlock操作之前，必须把此变量同步回主内存

但JMM存在一个问题，那就是当多条线程从主内存中取值然后load进自己的独立内存之后，在多条线程共同操作同一个变量的时候，线程与线程之间是不可见的。
在这里插入图片描述也就是说，当线程1和线程2将共享变量同时拿进自己的独立内存之后，线程1执行效率比较高，在很短的时间内就把变量操作修改完成并且最终提交了，而线程2此时并不知晓线程1已经把共享变量给修改了，从而一直在自己独立执行，而此时线程2操作的变量版本已经与主内存脱节了。

此类情况发生在数据库叫做脏读，发生在git叫做分支合并冲突，发生在线程中则有时候会产生线程不安全问题。

除了加锁，为了解决此类问题就引申出了volatile关键字。

二：Volatile关键字

Volatile是JVM提供的一种轻量级的同步机制，其特点是保证可见性，不保证原子性，禁止指令重排。

1.不保证可见性案列：

package JMM;

import java.util.concurrent.TimeUnit;

public class jmmTest {
    private static int number = 0;

    public static void main(String[] args) {
        new Thread(()->{
            while (number==0){

            }
        }).start();

        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        number=1;
        System.out.println(number);
    }


}

运行结果（number被修改后线程仍未停止）：
在这里插入图片描述

2.保证可见性案列：

package JMM;

import java.util.concurrent.TimeUnit;

public class jmmTest {
    
    //加上volatile关键字
    private static volatile int number = 0;

    public static void main(String[] args) {
        new Thread(()->{
            while (number==0){

            }
        }).start();

        try {
            TimeUnit.SECONDS.sleep(2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        number=1;
        System.out.println(number);
    }


}

运行结果（number数值变更后线程停止）：
在这里插入图片描述

2.不保证原子性：

当然也不能说完全的不保证原子性，对于本来就结构单一的读写操作，其本身就是原子性的所以能够保证，但如果像i++这样存在多个操做的东西是不保证原子性的。


package JMM;

import java.util.concurrent.TimeUnit;

public class jmmTest {

    //加上volatile关键字
    private static volatile int number = 0;

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

    public static void main(String[] args) {
        for (int i = 0; i <=20 ; i++) {
            new Thread(()->{
                while (number<=20000){
                    add();
                }
            }).start();
        }

        System.out.println(number);
    }

}

运行结果：

（这里的19957也不是唯一的，每次重新运行可能会产生诸多不同的结果，这是因为volatile不保证原子性导致的，再加上cpu执行速度飞快，该线程的use命令还没结束，下一个read和load命令可能就直接把它刷下去了，从而导致number++的操作根本来不及提交。且由于线程执行任务的时候是不能被打扰的，要么同时成功，要么同时失败，一旦线程被刷，则默认执行失败。）
在这里插入图片描述

并且可以看到，number++方法在底层并非仅仅执行了单个指令
在这里插入图片描述当然，也可以进一步使用原子级别的AtomicInteger来弥补，同时，像AtomicInteger，AtomicBoolean,AtomicLong这样的类底层有大量的native关键字，它们是直接与操作系统挂钩然后进行原子性保证的。

package JMM;

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class jmmTest {

    //加上volatile关键字
    private static volatile AtomicInteger number = new AtomicInteger();
    ;

    public static void add(){
        number.getAndIncrement();
    };

    public static void main(String[] args) {
        for (int i = 1; i <=20 ; i++) {
            new Thread(()->{
                for (int j = 0; j < 1000 ; j++) {
                    add();
                }
            }).start();
        }

    while (Thread.activeCount()>2){
        //线程数除了main和gc以外没有其他线程才停止礼让
        Thread.yield();
    }

        System.out.println(number);
    }

}

指令重排

指令重排本身是一种cpu执行的一种操作优化，也就是程序转进底层的时候，并不一定会保留原来的顺序。

打个比方：

int a = 90000;
int b = 1;
int c = 40;
int d = a+a;

代码写的顺序是a,b,c,d,但实际到底层的时候可能会被重排成b,a,c,d，个人认为，当a被初始的时候因为数值比较大，因此可能会占用更多的位，创建的时间相对较长，但b创建的时间则很短，如果为了让一个创建时间仅仅为1秒的变量去等待一个创建时间一个小时的变量，那这样的安排多少有些耽误事，因此产生了指令重排。
当然指令重排也不是毫无章法，abcd可能会编程bcad，也绝不可能变为dcba，因为d依赖着a，指令重排需要考虑数据的依赖性。

volatile禁止指令重排

实现原理是前后添加一个屏障，前门不让进，后门不让出，那自然就能保证指令不被重新排列了。
在这里插入图片描述

三：CAS

接下来补充一个内容，前面提到过AtomicInteger 以及其中的getAndIncrement方法可以实现原子级别的增加，接下来可以看一看它的源码。

在这里插入图片描述在return中我们可以看到有一个unsafe类，点进去看unsafe源码的时候发现对方声明了volatile级别的int，以及获取了相关的内存偏移地址
如果我们继续跟着objectFieldOffset点进去，就会发现与之并列的还有大量native关键字，这时候就说明java在试图走c的底层来试图与内存互动
在这里插入图片描述话题机会回到一开始的代码，在return unsafe.getAndAddInt(this, valueOffset, 1);中的getAndAddInt存在三个参数，第一个参数就是我们之前声明的AtomicInteger，valueOffset是内存地址来确定其唯一性，第三个参数就是一个1，意思是在原来数值的基础上准备递增的数，也就是+1操作。
于是继续进源码
在这里插入图片描述这里源码中的compareAndSwapInt就是说的CAS,而在getAndAddInt这里是一个自旋锁结构，只有当工作内存中的值和内存地址中的值是完全一致的时候，CAS才执行操作。