JUC多线程及高并发（一）之 volatile

最新推荐文章于 2023-03-13 17:00:31 发布

Hitomi_HXT

最新推荐文章于 2023-03-13 17:00:31 发布

阅读量196

点赞数

分类专栏： JUC

本文链接：https://blog.csdn.net/Hitomi_HXT/article/details/113860856

版权

JUC 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

JUC多线程及高并发（一）

一. JUC是什么
二. volatile的理解

一. JUC是什么

Package java.util.concurrent

二. volatile的理解

volatile是 Java虚拟机提供的 轻量级的 同步机制（就是乞丐版的synchronism）
包含三大特性：保证可见性，不保证原子性，禁止指令重排

（一）可见性

下面对这三大特性进行讲解，首先来看可见性
你需要明白什么是JMM：
JMM——Java内存模型，并不真实存在（就像12生肖里面的龙），它描述的是一组规则。通过这组规则，定义了程序中的各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

JMM关于同步的规定：
1 . 线程解锁前，必须把共享变量的值刷新回主内存
2 . 线程加锁前，必须读取主内存的最新值到自己的工作内存
3 . 加锁和解锁是同一把锁

由于JVM运行程序的实体是线程，而每个线程创建时 JVM都会为其创建一个工作内存（有些地方称为栈空间），工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写会主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，其简要访问过程：
在这里插入图片描述

上述图片解释说明：
数据传输速率：硬盘 < 内存 < < cache < CPU

上面提到了两个概念：主内存和工作内存
1 . 主内存：就是计算机的内存，也就是经常提到的8G内存，16G内存
2 . 工作内存：但我们实例化 new student，那么 age = 25 也是存储在主内存中

当同时有三个线程同时访问 student中的age变量时，那么每个线程都会拷贝一份，到各自的工作内存，从而实现了变量的拷贝

下面讲解JMM可见性的来源：
在这里插入图片描述
即：JMM内存模型的可见性，指的是当主内存区域中的值被某个线程写入更改后，其它线程会马上知晓更改后的值，并重新得到更改后的值。（说白了就是及时通知）

可见性代码验证：

package service;
import java.util.concurrent.TimeUnit;

class MyData { //假设为主物理内存
    int number = 0;
    public void addTo60() {
        this.number = 60;
    }
}

/**
 * 验证volatile的可见性
 * 1. 假设int number = 0， number变量之前没有添加volatile关键字修饰
 */
public class VolatileDemo {
    public static void main(String args []) {
        // 资源类
        MyData myData = new MyData();

        // AAA线程 实现了Runnable接口的，lambda表达式的
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "\t come in");
            // 线程睡眠3秒，假设在进行运算
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            // 修改number的值
            myData.addTo60();

            // 输出修改后的值
            System.out.println(Thread.currentThread().getName() + "\t update number value:" + myData.number);

        }, "AAA").start();

        while(myData.number == 0) {
            // main线程就一直在这里等待循环，直到number的值不等于零
        }

        // 按道理这个值是不可能打印出来的，因为主线程运行的时候，number的值为0，所以一直在循环
        // 如果能输出这句话，说明AAA线程在睡眠3秒后，更新的number的值，重新写入到主内存，并被main线程感知到了
        System.out.println(Thread.currentThread().getName() + "\t mission is over");
        
    }
}

输出结果：最后线程没有停止，并行没有输出 mission is over 这句话，说明没有用volatile修饰的变量，是没有可见性
在这里插入图片描述
当我们为number添加了volatile时

class MyData {
    /**
     * volatile 修饰的关键字，是为了增加 主线程和线程之间的可见性，只要有一个线程修改了内存中的值，其它线程也能马上感知
     */
    volatile int number = 0;

    public void addTo60() {
        this.number = 60;
    }
}

结果发生了变化：
在这里插入图片描述
主线程也执行完毕了，说明volatile修饰的变量，是具备JVM轻量级同步机制的，能够感知其它线程的修改后的值。

（二）不保证原子性

接下来我们来看不保证原子性
通过前面对JMM的介绍，我们知道，各个线程对主内存中共享变量的操作都是各个线程拷贝到自己的工作内存进行操作后再写回到主内存中的。

这就可能存在一个线程AAA修改了共享变量X的值，但是还未写入主内存时，另外一个线程BBB又对主内存中同一共享变量X进行操作，但此时A线程工作内存中共享变量X 对线程B来说是不可见的，这种工作内存与主内存同步延迟现象就造成了可见性问题。

原子性：
不可分割，完整性，也就是说某个线程正在做某个具体业务时，中间不可以被加塞或者被分割，需要具体完成，要么同时成功，要么同时失败。
数据库也经常提到事务具备原子性

原子性代码验证：

import java.util.concurrent.TimeUnit;

/**
 * 假设是主物理内存
 */
class MyData {
    /**
     * volatile 修饰的关键字，是为了增加 主线程和线程之间的可见性，只要有一个线程修改了内存中的值，其它线程也能马上感知
     */
    volatile int number = 0;

    public void addTo60() {
        this.number = 60;
    }

    /**
     * 注意，此时number 前面是加了volatile修饰，不保证原子性
     */
    public void addPlusPlus() {
        number ++;
    }
}

public class VolatileDemo {

    public static void main(String args []) {

        MyData myData = new MyData();

        // 创建20个线程，线程里面进行1000次循环
        for (int i = 0; i < 20; i++) {
            new Thread(() -> {
                // 里面
                for (int j = 0; j < 1000; j++) {
                    myData.addPlusPlus();
                }
            }, String.valueOf(i))//线程名
            .start();
        }

        // 需要等待上面20个线程都计算完成后，在用main线程取得最终的结果值
        // 这里判断线程数是否大于2，为什么是2？因为默认是有两个线程的，一个main线程，一个gc线程
        while(Thread.activeCount() > 2) {
            // yield表示不执行，由main让给别人执行
            Thread.yield();
        }

        // 查看最终的值
        // 假设volatile保证原子性，那么输出的值应该为：  20 * 1000 = 20000
        System.out.println(Thread.currentThread().getName() + "\t finally number value: " + myData.number);
	    // 最终结果我们会发现，number输出的值并没有20000，而且是每次运行的结果都不一致的，这说明了volatile修饰的变量不保证原子性
    }
}

如果加了synchronized，则输出结果number=20000

class MyData {
    volatile int number = 0;
    
    public void addTo60() {
        this.number = 60;
    }
    public synchronized void addPlusPlus() {
        number ++;
    }
}

为什么出现数值丢失
线程1 和线程2 同时修改各自工作空间中的内容，因为可见性，需要重新写入内存，但是线程1 在写入的时候，线程2也同时写入，导致线程1 的写入操作被挂起，这样就造成了在线程2 的写入后，线程1 覆盖了线程2 的值，造成了数据丢失的问题。

下面我们就针对 add() 这个方法，转换为字节码文件一探究竟

public void add() {
        n++;
    }

转换后的字节码文件（这里查看字节码的操作，是用到了IDEA的javap命令)，下面我们就针对 add() 这个方法的字节码文件进行分析

  public void add();
    Code:
       0: aload_0
       1: dup
       2: getfield      #2    // Field n:I
       5: iconst_1
       6: iadd
       7: putfield      #2    // Field n:I
      10: return

我们能够发现 n++这条命令，被拆分成了3个指令

执行getfield 从主内存拿到原始n
执行iadd 进行加1操作
执行putfileld 把累加后的值写回主内存

假设我们没有加 synchronized那么第一步就可能存在着，三个线程同时通过getfield命令，拿到主存中的 n值，然后三个线程，各自在自己的工作内存中进行加1操作，但他们并发进行 iadd 命令的时候，因为只能一个进行写，所以其它操作会被挂起，假设1线程，先进行了写操作，在写完后，volatile的可见性，应该需要告诉其它两个线程，主内存的值已经被修改了，但是因为太快了，其它两个线程，陆续执行 iadd命令，进行写入操作，这就造成了其他线程没有接受到主内存n的改变，从而覆盖了原来的值，出现写丢失，这样也就让最终的结果少于20000（线程的速度比volatile的可见性通知要更快）

如何解决
这说明，在多线程环境下 number ++ 在多线程环境下是非线程安全的，解决的方法有哪些呢？

在方法上加入 synchronized

 public synchronized void addPlusPlus() {
        number ++;
    }

我们能够发现引入synchronized关键字后，保证了该方法每次只能够一个线程进行访问和操作，最终输出的结果也就为20000

其他方法
上面的方法引入synchronized，虽然能够保证原子性，但是为了解决number++，而引入重量级的同步机制，有种杀鸡焉用牛刀。除了引用synchronized关键字外，还可以使用JUC下面的原子包装类，即刚刚的int类型的number，可以使用AtomicInteger(原子整型类）来代替

	 /**
     *  创建一个原子Integer包装类，默认为0
      */
    AtomicInteger atomicInteger = new AtomicInteger();
	//这里的atomicInteger 就相当于前面的number
    public void addAtomic() {
        // 相当于 有原子性的number++
        atomicInteger.getAndIncrement();
    }

然后同理，继续刚刚的操作

 // 创建10个线程，线程里面进行1000次循环
        for (int i = 0; i < 20; i++) {
            new Thread(() -> {
                // 里面
                for (int j = 0; j < 1000; j++) {
                    myData.addPlusPlus();
                    myData.addAtomic();
                }
            }, String.valueOf(i)).start();
        }

最后输出

// 假设volatile保证原子性，那么输出的值应该为：  20 * 1000 = 20000
        System.out.println(Thread.currentThread().getName() + "\t finally number value: " + myData.number);
        System.out.println(Thread.currentThread().getName() + "\t finally atomicNumber value: " + myData.atomicInteger);

下面的结果，一个是引入synchronized，一个是使用了原子包装类AtomicInteger，为什么AtomicInteger能保证原子性，是因为底层用了CAS。
在这里插入图片描述

（三）禁止指令重排

最后来看禁止指令重排
计算机在执行程序时，为了提高性能，编译器和处理器常常会对指令重排，一般分为以下三种：

源代码 -> 编译器优化的重排 -> 指令并行的重排 -> 内存系统的重排 -> 最终执行指令

单线程环境里面确保最终执行结果和代码顺序的结果一致

处理器在进行重排序时，必须要考虑指令之间的数据依赖性（先有你爸才有你)

多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的，结果无法预测。

案例1

public void mySort() {
	int x = 11;
	int y = 12;
	x = x + 5;
	y = x * x;
}

按照正常单线程环境，执行顺序是 1 2 3 4

但是在多线程环境下，可能出现以下的顺序：

2 1 3 4
1 3 2 4

上述的过程就可以当做是指令的重排，即内部执行顺序，和我们的代码顺序不一样

但是指令重排也是有限制的，即不会出现下面的顺序

4 3 2 1

因为处理器在进行重排时候，必须考虑到指令之间的数据依赖性

因为步骤 4：需要依赖于 y的申明，以及x的申明，故因为存在数据依赖，无法首先执行

注意:
若代码之间不存在数据依赖性，那么编译器就可能对指令进行重排；但是呢，有些指令进行重排后，就会造成数据出现问题，为了防止这样的结果出现，volatile就规定禁止指令重排。(volatile告诉编译器，你不要自作聪明帮我重排，我禁止你重排。)

案例2

public class ResortSeqDemo {
    int a= 0;
    boolean flag = false;

    public void method01() {
        a = 1;
        flag = true;
    }

    public void method02() {
        if(flag) {
            a = a + 5;
            System.out.println("reValue:" + a);
        }
    }
}

我们按照正常的顺序，分别调用method01() 和 method02() 那么，最终输出就是 a = 6

但是如果在多线程环境下，因为方法1 和方法2，他们之间不能存在数据依赖的问题，因此原先的顺序可能是

a = 1;
flag = true;

a = a + 5;
System.out.println("reValue:" + a);

但是在经过编译器，指令，或者内存的重排后，可能会出现这样的情况

flag = true;

a = a + 5;
System.out.println("reValue:" + a);

a = 1;

也就是先执行 flag = true后，另外一个线程马上调用方法2，满足 flag的判断，最终让a + 5，结果为5，这样同样出现了数据不一致的问题

为什么会出现这个结果：多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的，结果无法预测。

这样就需要通过volatile来修饰，来保证线程安全性

Volatile针对指令重排做了啥：

Volatile实现禁止指令重排优化，从而避免了多线程环境下程序出现乱序执行的现象

首先了解一个概念，内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，它的作用有两个：

保证特定操作的顺序
保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）

由于编译器和处理器都能执行指令重排的优化，如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障 禁止在 内存屏障前后的指令 执行重排序优化。内存屏障另外一个作用是刷新出各种CPU的缓存数，因此任何CPU上的线程都能读取到这些数据的最新版本。

在这里插入图片描述
也就是过在Volatile的写和读的时候，加入屏障，防止出现指令重排的

线程安全获得保证

工作内存与主内存 同步延迟现象 导致的可见性问题——可通过synchronized或volatile关键字解决，他们都可以使一个线程修改后的变量立即对其它线程可见
对于指令重排导致的可见性问题和有序性问题——可以使用volatile关键字解决，因为volatile关键字的另一个作用就是禁止重排序优化

（四）volatile应用场景

单例模式DCL代码
首先回顾一下，单线程下的单例模式代码

public class SingletonDemo {

    private static SingletonDemo instance = null;

    private SingletonDemo () {
        System.out.println(Thread.currentThread().getName() + "\t 我是构造方法SingletonDemo");
    }

    public static SingletonDemo getInstance() {
        if(instance == null) {
            instance = new SingletonDemo();
        }
        return instance;
    }

    public static void main(String[] args) {
        // 这里的 == 是比较内存地址
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
    }
}

输出的结果如下：
在这里插入图片描述
但是在多线程的环境下，我们的单例模式是否还是同一个对象？

public class SingletonDemo {

    private static SingletonDemo instance = null;

    private SingletonDemo () {
        System.out.println(Thread.currentThread().getName() + "\t 我是构造方法SingletonDemo");
    }

    public static SingletonDemo getInstance() {
        if(instance == null) {
            instance = new SingletonDemo();
        }
        return instance;
    }

    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                SingletonDemo.getInstance();
            }, String.valueOf(i)).start();
        }
    }
}

在这里插入图片描述

从上面的结果我们可以看出，我们通过SingletonDemo.getInstance() 获取到的对象，并不是同一个，而是被下面几个线程都进行了创建，那么在多线程环境下，单例模式如何保证呢？

解决方法：

引入synchronized关键字

  public synchronized static SingletonDemo getInstance() {
        if(instance == null) {
            instance = new SingletonDemo();
        }
        return instance;
    }

输出结果
在这里插入图片描述
我们能够发现，通过引入Synchronized关键字，能够解决高并发环境下的单例模式问题

但是synchronized属于重量级的同步机制，它只允许一个线程同时访问获取实例的方法，但是为了保证数据一致性，而减低了并发性，因此采用的比较少（synchronized保证一段代码在一定时间内只能被一个线程访问）

通过引入DCL（ Double Check Lock ）双端检锁机制
双端检锁就是说在加锁前后都进行判断。
打个有味道的比方：我上厕所前先看看厕所里面有没有人，然后没人就加锁，加完锁我还不放心，在检查一遍门有没有锁好。

public static SingletonDemo getInstance() {
        if(instance == null) {
            // 同步代码段的时候，进行检测
            synchronized (SingletonDemo.class) { //加锁
                if(instance == null) {
                    instance = new SingletonDemo();
                }
            }
        }
        return instance;
    }

最后输出的结果为：
在这里插入图片描述
从输出结果来看，确实能够保证单例模式的正确性，但是上面的方法还是存在问题的

DCL（双端检锁）机制不一定是线程安全的，原因是有指令重排的存在，加入volatile可以禁止指令重排

原因是在某一个线程执行到第一次检测，读取到 instance 不为null时，instance的引用对象可能没有完成实例化（也就是说这个空座位已经被分配出去了，但是这个位子的主人还没到）。因为 instance = new SingletonDemo()；可以分为以下三步进行完成：

memory = allocate(); // 1、分配对象内存空间（座位分配出去了)
instance(memory); // 2、初始化对象 (人在来的路上）
instance = memory; // 3、设置instance指向刚刚分配的内存地址，此时instance != null （人坐到座位上了）

但是我们通过上面的三个步骤，能够发现，步骤2 和步骤3之间不存在数据依赖关系，而且无论重排前还是重排后，程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的。

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

这样就会造成什么问题呢？

也就是当我们执行到重排后的步骤2，试图获取instance的时候，会得到null，因为对象的初始化还没有完成，而是在重排后的步骤3才完成，因此执行单例模式的代码时候，就会重新在创建一个instance实例（这就是为什么多线程的单例模式会不停创建对象实例的原因）

指令重排只会保证串行语义的执行一致性（单线程），但并不会关心多线程间的语义一致性

所以当一条线程访问instance不为null时，由于instance实例未必已初始化完成，这就造成了线程安全的问题

所以需要引入volatile，来保证出现指令重排的问题，从而保证单例模式的线程安全性

private static volatile SingletonDemo instance = null;

最终代码

public class SingletonDemo {

    private static volatile SingletonDemo instance = null;

    private SingletonDemo () {
        System.out.println(Thread.currentThread().getName() + "\t 我是构造方法SingletonDemo");
    }

    public static SingletonDemo getInstance() {
        if(instance == null) {
            // a 双重检查加锁多线程情况下会出现某个线程虽然这里已经为空，但是另外一个线程已经执行到d处
            synchronized (SingletonDemo.class) //b
            { 
           //c不加volitale关键字的话有可能会出现尚未完全初始化就获取到的情况。原因是内存模型允许无序写入
                if(instance == null) { 
                	// d 此时才开始初始化
                    instance = new SingletonDemo();
                }
            }
        }
        return instance;
    }

    public static void main(String[] args) {
//        // 这里的 == 是比较内存地址
//        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
//        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
//        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());
//        System.out.println(SingletonDemo.getInstance() == SingletonDemo.getInstance());

        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                SingletonDemo.getInstance();
            }, String.valueOf(i)).start();
        }
    }
}

综上：在高并发多线程的版本里面，我们的单例模式最终的写法是：

加入DCL双端检锁机制（单单这样不能保证线程安全）
在单例模式的对象前面用volatile修饰

Hitomi_HXT

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
JUC多线程及高并发（一）之 volatile

JUC多线程及高并发JUC是什么Package java.util.concurrent请谈谈你对volatile的理解volatile是 Java虚拟机提供的轻量级的同步机制（synchronism）包含三大特性：保证可见性，不保证原子性，禁止指令重排JMM——Java内存模型，并不真实存在（就像12生肖里面的龙），它描述的是一组规则。通过这组规则，定义了程序中的各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。JMM关于同步的规定：1 . 线程解锁前，必须
复制链接

扫一扫