❤你还怕多线程吗?全网最全多线程笔记(番外篇)❤

举报
XiaoLin_Java 发表于 2021/08/10 22:26:03 2021/08/10
【摘要】 介绍多线程并发修改变量不可见现象的原因之前,我们先看看另一种Java内存模型(和Java并发编程有关的模型):**JMM**。     JMM(Java Memory Model):Java内存模型是Java虚拟机规范中定义的一种内存模型,Java内存模型是标准化的,他屏蔽了底层不同计算机的硬件的不同     Ja

BugRapXiaoLin线

六、 volatile关键字

6.1、问题引入

public class VolatileThread extends Thread {

    // 定义成员变量
    private boolean flag = false ;
    public boolean isFlag() { return flag;}

    @Override
    public void run() {

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 将flag的值更改为true
        this.flag = true ;
        System.out.println("flag=" + flag);

    }
}

public class VolatileThreadDemo {// 测试类
    
    public static void main(String[] args) {

        // 创建VolatileThread线程对象
        VolatileThread volatileThread = new VolatileThread() ;
        volatileThread.start();

        // main方法
        while(true) {
            if(volatileThread.isFlag()) {
                System.out.println("执行了======");
            }
        }
    }
}

6.2、多线程下变量的不可见性

6.2.1、概述

    在介绍多线程并发修改变量不可见现象的原因之前,我们先看看另一种Java内存模型(和Java并发编程有关的模型):JMM

    JMM(Java Memory Model):Java内存模型是Java虚拟机规范中定义的一种内存模型,Java内存模型是标准化的,他屏蔽了底层不同计算机的硬件的不同

    Java内存模型描述了Java程序中各种变量(线程共享变量)的访问规则以及在JVM中将变量存储到内存和从内存中读取变量的底层细节。

​ JMM有以下规定:

  1. 所有的共享变量都存储于主内存(这里的变量是指实例变量和类变量,不包含局部变量,因为局部变量的线程是私有的,不存在竞争的问题)
  2. 每一个线程都有自己独立的工作内存,线程的工作内存保留了被线程使用的变量的工作副本
  3. 线程对变量的所有操作(读、取)都必须在工作内存中完成,而不能直接读写主内存的变量。

本地内存和主内存之间的关系:

在这里插入图片描述

6.2.2、问题分析

在这里插入图片描述

  1. 子线程1从主内存中读取到数据并复制到其对应的工作内存。
  2. 修改flag的值为true,但是这个时候flag的值还并没有写会主内存。
  3. 此时main方法读取到了flag的值为false。
  4. 当子线程1将flag的值写回去之后,由于main函数中的while(true)调用的是系统底层的代码,速度快,快到没有时间再去读取主内存中的值,所以此时while(true)读取到的值一直是flag = false
  5. 此时我们能想到的办法是,如果main线程从主内存中读取到了flag最新的值,那么if语句就可以执行了。

6.2.3、多线程下变量的不可见性的原因

  1. 每个线程都有自己的工作内存,线程都是从主内存中拷贝到共享变量的副本值
  2. 每个线程都是在自己的工作内存中操作共享变量的。

6.2.4、解决方案

6.2.4.1、加锁

while(true){
    synchronized(t){
        if(t.isFlag()){
            System.out.print("主线程进入循环")
        }
    }
}

    第一个线程进入synchronized代码块前后,执行过程如下:

  1. 线程获得锁
  2. 清空工作内存
  3. 从主内存中拷贝共享变量的最新值变成副本
  4. 执行代码
  5. 将修改后的值重新放回主内存中
  6. 线程释放锁

6.2.4.2、对共享变量使用volatile关键字修饰

    JMM中主内存和本地内存-第 2 页我们还可以对共享变量用volatile关键字修饰,volatile关键字的作用是在多线程并发下修改共享变量实现可见性。,一旦一线程修改了volatile修饰的变量,另一个线程可以立即读取到最新值。

在这里插入图片描述

6.2.5、volatile和synchronized

  • volatile只能修饰实例变量和类变量,而synchronized可以修饰方法以及代码块
  • volatile保证数据的可见性,但是不保证原子性(多线程进行写操作,不保证线程安全),而synchronized是一种排他互斥的机制,可以保证线程安全。

七、原子性

    所谓的原子性是指在一次操作或者多次操作中,要么所有的操作全部都得到了执行并且不会受到任何因素的干扰而中断,要么所有的操作都不执行。

7.1、问题引入

public class VolatileAtomicThread implements Runnable {

    // 定义一个int类型的遍历
    private int count = 0 ;

    @Override
    public void run() {
        // 对该变量进行++操作,100次
        for(int x = 0 ; x < 100 ; x++) {
            count++ ;					
            System.out.println("count =========>>>> " + count);
        }
    }

}

public class VolatileAtomicThreadDemo {

    public static void main(String[] args) {

        // 创建VolatileAtomicThread对象
        VolatileAtomicThread volatileAtomicThread = new VolatileAtomicThread() ;

        // 开启100个线程对count进行++操作
        for(int x = 0 ; x < 100 ; x++) {
            new Thread(volatileAtomicThread).start();
        }
        
    }

}

执行结果:不保证一定是10000

7.2、问题原理说明

    以上问题主要是发生在count++操作上,count++操作包含3个步骤:

  1. 从主内存中读取数据到工作内存
  2. 对工作内存中的数据进行++操作
  3. 将工作内存中的数据写回到主内存

    count++操作不是一个原子性操作,也就是说在某一个时刻对某一个操作的执行,有可能被其他的线程打断。

在这里插入图片描述

1)假设此时x的值是100,线程A需要对改变量进行自增1的操作,首先它需要从主内存中读取变量x的值。由于CPU的切换关系,此时CPU的执行权被切换到了B线程。A线程就处于就绪状态,B线程处于运行状态

2)线程B也需要从主内存中读取x变量的值,由于线程A没有对x值做任何修改因此此时B读取到的数据还是100

3)线程B工作内存中x执行了+1操作,但是未刷新之主内存中

4)此时CPU的执行权切换到了A线程上,由于此时线程B没有将工作内存中的数据刷新到主内存,因此A线程工作内存中的变量值还是100,没有失效。A线程对工作内存中的数据进行了+1操作

5)线程B将101写入到主内存

6)线程A将101写入到主内存

虽然计算了2次,但是只对A进行了1次修改。

7.3、volition的原子性

    在多线程环境下,volatile关键字可以保证共享数据的可见性,但是并不能保证对数据操作的原子性(在多线程环境下volatile修饰的变量也是线程不安全的)。

    在多线程环境下,要保证数据的安全性,我们还需要使用锁机制。

7.4、问题解决办法

7.4.1、使用锁机制(加锁)

​ 我们可以给count++操作添加锁,那么count++操作就是临界区的代码,临界区只能有一个线程去执行,所以count++就变成了原子操作。

缺点:性能差。

public class VolatileAtomicThread implements Runnable {

    // 定义一个int类型的变量
    private volatile int count = 0 ;
    private static final Object obj = new Object();

    @Override
    public void run() {

        // 对该变量进行++操作,100次
        for(int x = 0 ; x < 100 ; x++) {
            synchronized (obj) {
                count++ ;
                System.out.println("count =========>>>> " + count);
            }
        }

    }

}

7.4.2、使用原子类

7.4.2.1、概述

    Java从JDK5开始提供了java.util.concurrent.atomic包(简称Atomic包),这个包中的原子操作类提供了一种用法简单,性能高效,线程安全地更新一个变量的方式。我们可以使用原子类来保证原子性操作,从而保证线程安全。

7.4.2.2、常用API

​ 我们以Integer的原子类进行讲解。

方法 概述
public AtomicInteger(): 初始化一个默认值为0的原子型Integer
public AtomicInteger(int initialValue): 初始化一个指定值的原子型Integer
int get(): 获取值
int getAndIncrement(): 以原子方式将当前值加1,注意,这里返回的是自增前的值。
int incrementAndGet(): 以原子方式将当前值加1,注意,这里返回的是自增后的值。
int addAndGet(int data): 以原子方式将输入的数值与实例中的值(AtomicInteger里的value)相加,并返回结果。
int getAndSet(int value): 以原子方式设置为newValue的值,并返回旧值。
public class VolatileAtomicThread implements Runnable {

    // 定义一个int类型的变量,默认值是0,我们也可以指定长度
    private AtomicInteger atomicInteger = new AtomicInteger() ;

    @Override
    public void run() {
        // 对该变量进行++操作,100次
        for(int x = 0 ; x < 100 ; x++) {
            int i = atomicInteger.getAndIncrement();
            System.out.println("count =========>>>> " + i);
        }

    }

}

7.5、原子类CAS机制

    CAS的全成是: Compare And Swap(比较再交换); 是现代CPU广泛支持的一种对内存中的共享数据进行操作的一种特殊指令。CAS可以将read-modify-check-write转换为原子操作,这个原子操作直接由处理器保证。

    CAS机制当中使用了3个基本操作数:内存地址V,旧的预期值A,要修改的新值B。

7.5.1、CAS机制详解

  1. 在内存地址V当中,存储着值为10的变量。

在这里插入图片描述

  1. 此时线程1想要把变量的值增加1。对线程1来说,旧的预期值A=10,要修改的新值B=11。

在这里插入图片描述

  1. 在线程1要提交更新之前,另一个线程2抢先一步,把内存地址V中的变量值率先更新成了11。

在这里插入图片描述

  1. 线程1开始提交更新,首先进行A和地址V的实际值比较(Compare),发现A不等于V的实际值,说明值已经被更改过了,提交失败。

在这里插入图片描述

  1. 线程1重新获取内存地址V的当前值,并重新计算想要修改的新值。此时对线程1来说,A=11,B=12。这个重新尝试的过程被称为自旋。

在这里插入图片描述

  1. 这一次比较幸运,没有其他线程改变地址V的值。线程1进行Compare,发现A和地址V的实际值是相等的,说明并没有人修改过值。

在这里插入图片描述

  1. 线程1进行SWAP(交换),把地址V的值替换为B,也就是12。

在这里插入图片描述

7.6、乐观锁和悲观锁

​    CAS和Synchronized都可以保证多线程环境下共享数据的安全性。那么他们两者有什么区别?

7.6.1、悲观锁

​    Synchronized是从悲观的角度出发,是一个典型的悲观锁。

​    总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁。

​    共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程。因此Synchronized我们也将其称之为悲观锁。jdk中的ReentrantLock也是一种悲观锁。性能较差!

7.6.2、乐观锁

​    CAS是从乐观的角度出发,总是假设最好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。

​    CAS这种机制我们也可以将其称之为乐观锁。综合性能较好!很多数据库都会使用到乐观锁机制。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。