当前位置: 首页 > article >正文

JavaEE-多线程初阶(3)

目录

1.线程的状态

1.1 NEW、RUNNABLE、TERMINATED

1.2 TIMED_WAITING

1.3 WAITING

1.4 BLOCKED

2.多线程带来的风险-线程安全(重点)

2.1 观察线程不安全的现象

2.2 分析产生该现象的原因

2.3 产生线程安全问题的原因

2.3.1 抢占式执行(根本)

2.3.2 多个线程同时修改同一个变量

2.3.3 修改操作,不是原子的

2.3.4 内容可见性问题

2.3.5 指令从排序

2.4 如何解决线程安全问题

2.4.1 抢占式执行

2.4.2 多个线程同时修改同一个变量

2.4.3 修改操作,不是原子的

解决方案

加锁:synchronized

synchronized的变种写法



1.线程的状态

线程的所有状态如下:

NEW: 安排了⼯作, 还未开始⾏动
RUNNABLE: 可⼯作的. ⼜可以分成正在⼯作中和即将开始⼯作.
BLOCKED: 这⼏个都表⽰排队等着其他事情
WAITING: 这⼏个都表⽰排队等着其他事情
TIMED_WAITING: 这⼏个都表⽰排队等着其他事情
TERMINATED: ⼯作完成了.

1.1 NEW、RUNNABLE、TERMINATED

对于这三个状态的解释:

NEW:new了Thread对象,还没start

RUNNABLE :就绪状态,可以分成以下两种情况(正在工作或者即将开始工作):

(1)线程正在cpu上执行
(2)线程随时可以去cpu上执行

TERMINATED:内核中的线程已经结束了,但是Thread对象还在

    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            System.out.println("线程t1开始执行...");
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            System.out.println("t1线程结束...");
        });
        System.out.println(t1.getState());
        t1.start();
        Thread.sleep(0,500);
        System.out.println(t1.getState());
        t1.join();
        System.out.println(t1.getState());
    }

执行结果:

1.2 TIMED_WAITING

指定时间的阻塞

• 线程阻塞(不参与 cpu 调度,不继续执行了)

阻塞的时间是有上限的

Thread.sleep(时间);会进入到TIMED_WAITING状态

另外,join(时间)也会进入到TIMED_WAITING状态:

1.3 WAITING

死等,没有超时时间的阻塞等待

1.4 BLOCKED

也是一种阻塞,比较特殊,是由于锁导致的阻塞

2.多线程带来的风险-线程安全(重点)

2.1 观察线程不安全的现象

案例:

创建一个静态变量count=0;

在main方法里创建两个线程t1和t2

两个线程内分别循环五万次count++操作

最后打印出count的值:

public class Demo10 {
    public static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }
}

按照道理来说,count进行了总共十万次count++操作,打印出来的值应该是十万,实际上却并非如此,执行代码:

这样的代码很明显是有bug的,实际执行效果与预期效果不符合就叫做bug。

这样的问题,是多线程并发执行引发的问题。

如果调换代码的执行程序,把t1线程和t2线程的并行改成串行(一个执行完了再执行另一个)

结果又变成正确的了:

执行结果:

很明显,当前的bug是由于多线程的并发执行代码引起的bug

这样的bug,就称为“线程安全问题”,或者叫做“线程不安全”

反之,如果一个代码在多线程并发执行的环境下也不会出现类似上述的bug

这样的代码就称为“线程安全”

2.2 分析产生该现象的原因

站在 CPU 的角度来看count++,这个操作看起来是一行代码,实际上对应到三个CPU指令:

1.load,把内存中的值(count变量)读取到寄存器中

2.add,把指定的寄存器中的值进行+1操作(结果还是在这个寄存器中)

3.save,把寄存器中的值,写回到内存中

CPU执行这三条指令的过程中,随时有可能触发线程的调度切换(如下所示):

指令1 指令2 指令3 线程切走

指令1  指令2  线程切走  指令3

指令1 线程切走 指令2 指令3

指令1 线程切走 指令2 线程切走 指令3

但是由于操作系统的调度是随机的,不可预期的

执行任何一个指令的过程中都有可能触发上述的“线程切换”的操作

也就是说,随机调度(或者叫抢占式执行)就是线程安全问题的罪魁祸首。

t1线程和t2线程的执行过程可能会出现如下情况(只举了个别例子,可能还有别的情况):

对于执行结果:打 √ 的为正确结果,× 为错误结果。

对于其中某种正确情况的具体执行过程如下:

对于其中某种错误情况的具体执行过程如下:

可以看到:

t1线程t2线程分别进行了一次count++操作,理论上count的值应为2,实际上由于随机调度,t1的寄存器和t2的寄存器都读取了内存的初始值0,最终执行完两次count++后count的值为1

由于线程执行的过程中有可能(大概率)会发生上述的错误情况,因此代码的执行结果总是<=100000


如果降低单个线程的循环次数,会发现能运行出正确的结果:

运行结果:

出现这种现象的原因:

事实上,线程安全问题依旧存在,只不过概率变低了。

单个线程执行的count++次数会影响到这个线程的运行时间,即运行50次比运行50000次要快得多

因为运行的太快了,很可能在t2.start()执行之前,t1线程就执行完了

等到后续t2线程的执行,就变成了串行执行

2.3 产生线程安全问题的原因

2.3.1 抢占式执行(根本)

抢占式执行:操作系统对于线程的调度是随机的

抢占式执行策略

最初诞生于多任务操作系统的时候,是非常重大的发明

后世的操作系统,都是一脉相承

2.3.2 多个线程同时修改同一个变量

如果是一个线程,修改一个变量---没问题

如果是多个线程不是同时修改同一个变量---没问题

如果是多个线程,修改不同变量---没问题(不会出现中间结果相互覆盖的情况)

如果是多个线程读取同一个变量---没问题(该变量不可修改)

2.3.3 修改操作,不是原子的

原子:

如果一个操作只是对应到一个cpu指令,那么就可以认为它是原子的

cpu就不会出现“一条指令执行到一半”这样的情况

反之,如果一个操作对应到多个cpu指令,那么它就不是原子的,例如:

++

--

+=

-=

........

2.3.4 内容可见性问题

后续再讨论

2.3.5 指令从排序

后续再讨论

2.4 如何解决线程安全问题

2.4.1 抢占式执行

抢占式执行是操作系统的底层设定,程序员无法左右。

2.4.2 多个线程同时修改同一个变量

和代码的结构直接相关

可以调整代码结构,规避一些线程不安全的代码

但是这样的方案不够通用

Java中有个东西:

String 就是采用了“不可变”特性,确保线程安全

2.4.3 修改操作,不是原子的

解决方案

Java中解决线程安全问题,最主要的方案就是:加锁

通过加锁操作,让不是原子的操作,打包成一个原子的操作

计算机中的锁,和生活中的锁,是同样的概念:互斥/排他

把锁“锁上”称为“加锁”

把锁“解开”称为“解锁”

一旦把锁加上了,其他人要想加锁,就得阻塞等待

对于上述例子的count++操作,它并非是原子的,此时就可以使用锁,把刚才不是原子的count++

包裹起来,在count++之前,先加锁,然后进行count++,计算完毕之后,再解锁

(此时在执行三步走的过程中,其他线程就没法“插队”了)

加锁操作,不是把线程锁死到cpu上,禁止这个线程被调度走

而是禁止其他线程重新加这个锁,避免其他线程的操作在当前线程执行的过程中“插队”


加锁:synchronized

加锁 / 解锁 本身是操作系统提供的api

很多编程语言都对这样的api进行了封装

大多数的封装风格,都是采取两个函数:

加锁 lock();

//执行一些要保护起来的逻辑

解锁 unlock();

Java中使用 synchronized 这样的关键字,搭配代码块来实现类似的效果:

synchronized(){ //进入代码块,相当于加锁

//执行一些要保护起来的逻辑

}出了代码块,相当于解锁

使用synchronized对上述案例进行加锁:

可以看到括号内需要填入参数,应该填入什么呢?

填写的是,用来加锁的对象。要 加锁 / 解锁,前提是得先有一个锁

在Java中任何一个对象都可以用作“锁”

这个对象的类型是什么不重要

重要的是,是否有多个线程针对这同一个对象加锁(竞争同一把锁)

再次执行代码,线程安全问题得到了解决:

【注意】

两个线程,针对同一个对象加锁,才会产生互斥效果

(一个线程加上了锁,另一个线程就得阻塞等待,等到第一个线程释放锁,才有机会)

如果是不同的锁对象,此时不会有互斥效果,线程安全问题并没有得到解决:

代码执行结果,依旧存在线程安全问题:


synchronized的变种写法

可以使用 synchronized 修饰方法

这种写法跟之前的写法产生的效果是一样的,执行代码:

修饰方法的写法还能继续变形:使用synchronized修饰方法,就相当于是针对this进行加锁

这种写法跟上面的效果也是一样的。

StringBuffer、Vector这些类里面有些方法就是带有synchronized的:

因此,StringBuffer是线程安全的,而StringBuilder线程不安全。

而方法之中,还有一个特殊情况,static修饰的方法不存在this

此时,synchronized修饰static方法相当于针对类对象加锁:


如果哪里有疑问的话欢迎来评论区指出和讨论,如果觉得文章有价值的话就请给我点个关注还有免费的收藏和赞吧,谢谢大家


http://www.kler.cn/a/380567.html

相关文章:

  • OpenCV相机标定与3D重建(26)计算两个二维点集之间的部分仿射变换矩阵(2x3)函数 estimateAffinePartial2D()的使用
  • 数据分析思维(五):分析方法——假设检验分析方法
  • LightGBM分类算法在医疗数据挖掘中的深度探索与应用创新(上)
  • python使用pip进行库的下载
  • vscode 快速切换cangjie版本
  • SAP抓取外部https报错SSL handshake处理方法
  • 前端存储大量数据indexedDB
  • C++优选算法四 前缀和
  • 一、SpringMVC简介
  • Flutter鸿蒙next中封装一个列表组件
  • 电动缸在汽车领域的应用
  • 雷池社区版新版本功能防绕过人机验证解析
  • 普林斯顿微积分读本PDF(英文版原版)
  • 使用css和html制作导航栏
  • 【初阶数据结构篇】链式结构二叉树(续)
  • 计算机网络:网络层 —— 路由选择与静态路由配置
  • Linux 服务器使用指南:从入门到登录
  • 探索数据结构:数组与链表
  • 2024 年 QEMU 峰会纪要
  • Spring IoC——依赖注入
  • 每日算法练习
  • 从 vue 源码看问题 — vue 如何进行异步更新?
  • 深入理解 Linux df 命令:用法详解与使用示例
  • 【Linux】从零开始使用多路转接IO --- epoll
  • 易盾增强版滑块识别/易盾识别/滑块识别/增强版滑块识别/易盾滑块本地识别
  • 前端通过nginx部署一个本地服务的方法