文章目录
前言
📕各位读者好, 我是小陈, 这是我的个人主页
📗小陈还在持续努力学习编程, 努力通过博客输出所学知识
📘如果本篇对你有帮助, 烦请点赞关注支持一波, 感激不尽
📙 希望我的专栏能够帮助到你:
JavaSE基础: 基础语法, 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
Java数据结构: 顺序表, 链表, 堆, 二叉树, 二叉搜索树, 哈希表等
JavaEE初阶: 多线程, 网络编程, TCP/IP协议, HTTP协议, Tomcat, Servlet, Linux, JVM等(正在持续更新)
上篇[多线程基础2]主要介绍了 : Thread类 的构造方法, 常用成员属性, 常用成员方法以及多线程的状态, 状态转换
本篇继续介绍多线程相关的基础内容,
内容较多, 分为若干篇持续分享
提示：是正在努力进步的小菜鸟一只，如有大佬发现文章欠佳之处欢迎批评指点~ 废话不多说，直接上干货！
一、线程不安全的原因
如何定义
线程是否安全
?
如果多线程环境的代码执行结果, 和单线程环境的代码执行结果一致, 则认为线程是安全的, 否则认为线程不安全
下面介绍线程不安全的几个原因
1, 多线程调度的随机性(抢占式执行)
这是导致多线程环境下 线程不安全 的最根本原因
由于多个线程是 “抢占式执行的” , 所以造成了多线程调度的随机性, 无序性
多线程在 CPU 上并发执行, 而 CPU 只能看懂二进制的指令, 所以多线程调度时的随机性, 无序性, 就有可能造成这些指令的混乱
所以多个线程互相影响起来, 也是无迹可寻的
2, 原子性
原子性是指 : 不可分割的最小单位, CPU 执行的一条指令, 就是满足原子性的
然而一行 Java 代码(即便很简单易懂), 也不一定满足原子性, 因为这一行代码可能分为
很多条指令
如果不满足原子性, 在多线程环境下, CPU 正在执行线程 A 的代码对应的指令, 此时另一个线程过来插了一脚, CPU 去执行线程 B 的代码对应的指令, 整个程序就有可能发生错误
3, 内存可见性
可见性指 : 一个线程对共用变量的修改, 能够及时地被其他线程看到
如果不满足内存可见性, 在多线程环境下, 线程 A 修改了某个共用变量的值, 线程 B 看不到这这共用变量被修改了, 还在使用修改前的值, 程序就有可能发生错误
哎? 为啥线程 A 修改了共用变量, 线程 B 不能及时看到呢? 这就要谈谈 Java 内存模型 了
3.1, Java 内存模型(JMM)
线程之间的共用变量存在 主内存 (Main Memory)
每一个线程都有自己的 “工作内存” (Working Memory)
当线程要读取一个共用变量的时候, 会先把变量从主内存拷贝到工作内存, 再从工作内存读取数据
当线程要修改一个共用变量的时候, 也会先修改工作内存中的副本, 再同步回主内存
这里的主内存才是平常说的内存, 工作内存 其实是 寄存器 和 高速缓存
从寄存器中读取数据, 比从内存中读取数据快了
3 ~ 4 个数量级( 1k ~ 1w 倍)
, 而从内存中读取数据, 比从硬盘中读取数据快了
3 ~ 4 个数量级( 1k ~ 1w 倍)
,
所以读取速度 : 寄存器 >> 内存 >> 硬盘 (高速缓存的速度介于寄存器和内存之间)
不满足内存可见性的情况 :
比如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的, 但是
如果只是第一次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问内存了, 效率就大大提高了
此时修改线程A 的工作内存中的值, 线程B 的工作内存不一定会及时变化
为什么Java官方要把 寄存器和高速缓存, 定义成一个新的术语"工作内存"?
因为早期的CPU中是没有高速缓存的, 并且由于Java的可移植性, 为了应付不同电脑上的硬件软件差异, 保证文档的规范性, 适用性, 定义了"工作内存"
4, 指令重排序
例如 : 如下有四条指令
1, 我从宿舍出发
2, 要去食堂吃饭
3, 要去快递站拿快递
4, 要帮舍友带饭
按照1 --> 2 --> 3 --> 4 的顺序执行, 我的路线是这样的 :
把 3 , 4 互换位置后, 按照1 --> 2 --> 4 --> 3 的顺序执行, 我的路线是这样的 :
在 保证逻辑不变 的前提下, 更改多条指令的顺序, 从而提高程序执行效率, 这就是指令重排序
有些指令重排序能够提高执行效率 有时不能
这一点在单线程环境下比较容易判断, 但是在多线程环境下就没那么容易了, 多线程的代码执行复杂程度更高, 编译器很难在编译阶段对代码的执行效果进行预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价, 这是指令重排序可能造成的弊端
并且重排序是一个比较复杂的话题, 涉及到 CPU 以及编译器的一些底层工作原理, 此处不做过多讨论, 了解即可
下面通过实际代码简单展示一下线程不安全的情况
二、示例1
1, 代码示例
首先定义一个 Counter类
classCounter{privateint number =0;publicvoidadd(){
number++;}publicintgetCount(){return number;}}
我们创建两个线程，两个线程都调用
add方法
5k 次，两个线程结束后主线程中获取 number 的值
publicstaticvoidmain(String[] args)throwsInterruptedException{Counter counter =newCounter();Thread thread1 =newThread(()->{for(int i =0; i <5000; i++){
counter.add();}});Thread thread2 =newThread(()->{for(int i =0; i <5000; i++){
counter.add();}});
thread1.start();
thread2.start();
thread1.join();
thread2.join();System.out.println(counter.getCount());}
预期结果 : 最终number的值是1w，来看运行结果
实际结果 : 并不是 1w, 而是小于1w, 并且多次运行的执行结果都不一样
2, 原因分析
原因就在于 add方法 调用后的 number++ 这个操作并不是原子的
这一行代码看似简单易懂，实际上是三条 CPU 指令 ：
1, load 从内存中读取 number 的值, 到寄存器中
2, add 修改寄存器中 number 的值, 把 number + 1
3, save 把寄存器中的值写回到内存中
其实就是上述的 Java内存模型 的机制
两个线程并发执行时, 如果是 理想情况 :
这三条指令没有相互交错, 就不会对最后的值产生影响, 这是 理性情况
对应的, 如果
thread1线程
在 CPU 上执行到 load 指令时, 读到 number 的值为 1 , 本该继续执行后两条指令, 但是突然被
thread2线程
抢占执行了, CPU 开始执行
thread2线程
的三条指令, 就是 非理想情况 :
只要是
number++
时, 两个线程发生了 “抢占式” 执行, 导致了有一次修改无效(被覆盖), 就是 非理性情况
正是因为
number++
这个操作不是原子的, 所以才会在 “抢占式” 执行时产生问题, 可是, 只要是多线程环境, 就无法改变 “抢占式” 执行这一机制, 那有没有一种可能, 我们把
number++
变成原子性的呢?
当然可以, 就是通过 “加锁” 来实现 : 使用 snychronized 关键字
3, 解决方法 : synchronized 关键字
只需要在 Counter类 中的 add方法上, 加一个 synchronized关键字
synchronizedpublicvoidadd(){
number++;}
来看运行结果 :
符合上面示例的预期结果
synchronized关键字 最主要的特性就是 : 互斥
例如 : 线程 A 执行到对象 Counter 的
synchronized 修饰的代码块
中时, 线程 B 如果也同时执行到对象 Counter 的
synchronized 修饰的代码块
, 线程 B 就会阻塞等待
进入 synchronized 修饰的代码块, 相当于 加锁
退出 synchronized 修饰的代码块, 相当于 解锁
其实很好理解 :
张三去上厕所, 进去之后
锁门 (加锁)
, 此时李四也想上厕所, 他就得在门口憋着, 等张三
出来 (解锁)
之后, 才能进去厕所,
锁门 (加锁)
可如果在张三还没出来的时候, 李四和王五都想上厕所, 那么等张三
出来 (解锁)
之后, 李四和王五就要
抢这个厕所(锁竞争
), 谁抢到谁就进去厕所,
锁门(加锁)
,
李四和王五 抢 的过程就是多线程的抢占式执行
厕所, 其实就是一个锁对象
“锁” 这个话题很丰富, 以后还会详细介绍
三、示例2
1, 代码示例
定义一个成员属性 n , 初始化为 0 , 再创建两个线程
在第一个线程中, 如果 n 为 0 , 一直循环, 没有循环体, 在第二个线程中, 从控制台输入整数, 赋值给 n
publicstaticint n =0;publicstaticvoidmain(String[] args){Thread thread1 =newThread(()->{while(n ==0){}System.out.println(" n 不是 0 了, 循环结束");});Thread thread2 =newThread(()->{Scanner scanner =newScanner(System.in);
n = scanner.nextInt();});System.out.print("请输入一个整数 : ");
thread1.start();
thread2.start();
预期结果 : 如果输入的 n 不是 0 , thread1 就会退出循环, 执行打印语句
实际结果 : 并没有退出循环, 但 n 的值确实被修改了
2, 原因分析
既然 n 的值确实被修改了, 那么 thread1线程 中的循环没有退出的原因只能是, thread1线程 没有读取到修改过的 n 的值, 而是一直读取原本的 n 的值
因为在 while 循环中, 没有循环体, 在整个循环中只有两条指令
1, load : 从内存中读取 n 的值到寄存器
2, 从寄存器中读取 n , 比较 n 的值和 0 是否相同
注意, n 的值在内存中被修改是 thread2 里干的事, 和 thread1 线程无关
由于从寄存器中读取数据, 比从内存中读取数据快了
3 ~ 4 个数量级( 1k ~ 1w 倍)
, 所以对于这一整个循环来说, 执行 1次 指令1, 就可以执行 1k ~ 1w次 指令2
那么从内存中读取 n 的值就成了 “负担” , 所以编译器就进行了优化, 直接省去了指令1, 那么 thread1线程 中, n 的值就永远为 0
这就导致了上述实例中, 对于 n 这个共用变量, 在 thread1线程 和 thread2线程 中不满足 内存可见性, 如何解决这个问题呢? 使用 volatile关键字
3, 解决方法 : volatile 关键字
只需要在共用变量 n 之前加上 volatile关键字 即可
volatilepublicstaticint n =0;
volatile 修饰的变量, 能够保证 内存可见性, 能够 强制执行内存和寄存器之间的读写指令, 虽然导致速度慢了, 但是数据变的更准确了
volatile 还可以禁止指令重排序
但是 volatile 不保证原子性, 如果把 示例1 中的 synchronized 关键字 改成 volatile 关键字, 最终执行结果仍然不符合预期
所以, volatile 关键字 适合于一个线程读, 一个线程写的情况
六、wait 和 notify
有些场景下, 可能一个线程需要等另一个线程结束以后再执行, 可以用 join方法
但有些时候, 可能一个线程需要等另一个线程执行一会再执行, 这种情况下就不能用 join方法 了, 需要使用 wait方法 搭配 notify方法
线程 A 调用 wait方法 是让线程 A 进入 WAITING 阻塞状态, 不再继续执行, 由其他线程(比如线程 B)调用 notify方法 来唤醒正在 WAITING 的线程 A
wait 和 notify 都是 Object类 的方法, 并且要写在 synchronized 代码块中
wait 方法, join方法, sleep方法, 这些能造成线程进入堵塞状态的方法都需要用 try-catch 处理 InterruptedException异常
publicstaticvoidmain(String[] args){Object object =newObject();Thread thread =newThread(()->{synchronized(object){System.out.println("wait 开始");try{
object.wait();}catch(InterruptedException e){
e.printStackTrace();}System.out.println("wait 结束");}});
thread.start();}
可以看到运行结果: wait并没有结束, 说明 thread线程 正在堵塞
wait方法调用后, 有三步要走 :
1, 释放当前的锁
2, 进入WAITING 状态, 阻塞等待(等待被 notify 唤醒)
3, 被 notify 唤醒了, 尝试重新获取锁, 继续执行未执行完的代码
如果再创建一个线程 thread2, 在 thread2线程 中调用 notify方法, 就可以唤醒 thread线程中正在堵塞等待的 wait方法
注意, notify 方法也要写在 synchronized 代码块中, 并且锁对象必须和 wait方法 的锁对象一致, 否则无法唤醒 wait方法
Thread thread2 =newThread(()->{synchronized(object){System.out.println("notify 开始");
object.notify();System.out.println("notify 结束");}});
thread2.start();
由于 notify方法 和 wait方法的锁对象一致, 锁对象一致, 就会产生锁竞争, 所以 notify方法 结束后, 唤醒 wait方法 的阻塞等待状态, 但 wait方法 需要等 notify方法 把锁释放, 才能重新获取锁, 所以
wait方法 又多了一个等待 notify方法 释放锁的过程
综上, wait方法 总共堵塞了两次, 但本质不同 :
1, 第一次, wait方法 开始后, 堵塞的目的是 : 等待被唤醒
2, 第二次, 其他线程的 notify方法 结束后, 堵塞的目的是 : 等待锁释放后拿到锁
如果没有使用 wait方法 就使用 notify方法 , 只能认为是 : 唤醒了个寂寞, 没有任何效果, 也不会报错
wait方法 也可以设置一个参数, 表示等待多久, 如果超出这个限制还没有被唤醒, 就自动被唤醒, 相当于自己给自己定了个闹钟
wait方法 和 sleep方法 的区别 ?
相同点在于 :
1, 都能让线程等一会, 并且设定时间上限
2, 都能提前被唤醒
但两个方法使用的场景和目的就有本质不同 :
1, wait方法 是为了在多线程环境下, 协调线程之间的执行顺序, 而 sleep方法 只是单纯的让线程休眠
2, wait方法 需要搭配锁使用, sleep方法 不需要
总结
以上就是本篇的全部内容, 主要介绍了
多线程环境下线程不安全的原因和解决方案, 简单介绍了 synchronized关键字 和 volatile 关键字, 以及 wait 和 notify 方法的搭配使用
如果本篇对你有帮助，请点赞收藏支持一下，小手一抖就是对作者莫大的鼓励啦😋😋😋~
上山总比下山辛苦
下篇文章见
版权归原作者 灵魂相契的树 所有， 如有侵权，请联系我们删除。