本节⽬标
- 掌握什么是线程不安全及解决思路
- 掌握 synchronized、volatile 关键字
一、多线程带来的的⻛险-线程安全 (重点)
1 观察线程不安全
package Thread.ThreadUnsecurity;
public class Unsecurity {
public static int count=0;
public static void main(String[] args) throws InterruptedException {
Thread thread1=new Thread(()->{
for (int i = 0; i < 50000; i++) {
count++;
}
});
Thread thread2=new Thread(()->{
for (int i = 0; i < 50000; i++) {
count++;
}
});
thread1.start();
//防止还没自增完成就开始打印
thread1.join();
thread2.join();
System.out.println(count);// 预期结果应该是 10w
}
}
⼤家观察下是否适⽤多线程的现象是否⼀致?同时尝试思考下为什么会有这样的现象发⽣呢?
2 线程安全的概念
想给出⼀个线程安全的确切定义是复杂的,但我们可以这样认为:
如果多线程环境下代码运⾏的结果是符合我们预期的,即在单线程环境应该的结果,则说这个程序是线程安全的。
3 线程不安全的原因
1.线程调度是随机的,抢占式执行 (这是线程安全问题的 罪魁祸⾸)
随机调度使⼀个程序在多线程环境下, 执⾏顺序存在很多的变数.
程序猿必须保证 在任意执⾏顺序下 , 代码都能正常⼯作.
2.多个线程修改同⼀个变量(修改共享数据)
上⾯的线程不安全的代码中, 涉及到多个线程针对 count 变量进⾏修改.
此时这个 count 是⼀个多个线程都能访问到的 "共享数据"
3.修改操作不是原子性的
什么是原⼦性?
我们把⼀段代码想象成⼀个房间,每个线程就是要进⼊这个房间的⼈。如果没有任何机制保证,A进⼊房间之后,还没有出来;B 是不是也可以进⼊房间,打断 A 在房间⾥的隐私。这个就是不具备原⼦性的。
那我们应该如何解决这个问题呢?是不是只要给房间加⼀把锁,A 进去就把⻔锁上,其他⼈是不是就进不来了。这样就保证了这段代码的原⼦性了。
有时也把加锁这个现象叫做同步互斥,表⽰操作是互相排斥的。
⼀条 java 语句不⼀定是原⼦的,也不⼀定只是⼀条指令
⽐如刚才我们看到的 n++,其实是由三步操作组成的:
1. 从内存把数据读到 CPU
2. 进⾏数据更新
3. 把数据写回到 CPU
不保证原⼦性会给多线程带来什么问题
如果⼀个线程正在对⼀个变量操作,中途其他线程插⼊进来了,如果这个操作被打断了,结果就可能是错误的。
这点也和线程的抢占式调度密切相关. 如果线程不是 "抢占" 的, 就算没有原⼦性, 也问题不⼤.
- 内存可⻅性--->编辑器优化
Java 内存模型 (JMM)
JMM: Java虚拟机规范中定义了Java内存模型.
⽬的是屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到⼀致的并发效果.
- 线程之间的共享变量存在 主内存 (Main Memory).
- 每⼀个线程都有⾃⼰的 "⼯作内存" (Working Memory) .(这里工作内存可以理解为register寄存器)
- 当线程要读取⼀个共享变量的时候, 会先把变量从主内存拷⻉到⼯作内存, 再从⼯作内存读取数据.
- 当线程要修改⼀个共享变量的时候, 也会先修改⼯作内存中的副本, 再同步回主内存.
由于每个线程有⾃⼰的⼯作内存, 这些⼯作内存中的内容相当于同⼀个共享变量的 "副本". 此时修改线程1 的⼯作内存中的值, 线程2 的⼯作内存不⼀定会及时变化.
为什么不直接把Working Memory写成register?
具体示例
1) 初始情况下, 两个线程的⼯作内存内容⼀致.
2) ⼀旦线程1 修改了 a 的值, 此时主内存不⼀定能及时同步. 对应的线程2 的⼯作内存的 a 的值也不⼀定能及时同步.
这个时候代码中就容易出现问题.
此时引⼊了两个问题:
- 为啥要整这么多内存?
- 为啥要这么⿇烦的拷来拷去?
1) 为啥整这么多内存?
实际并没有这么多 "内存". 这只是 Java 规范中的⼀个术语, 是属于 "抽象" 的叫法.
所谓的 "主内存" 才是真正硬件⻆度的 "内存". ⽽所谓的 "⼯作内存", 则是指 CPU 的寄存器和⾼速缓存.
2) 为啥要这么⿇烦的拷来拷去?
因为 CPU 访问⾃⾝寄存器的速度以及⾼速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级, 也就是⼏千倍, 上万倍).
⽐如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的. 但是如果只是第⼀次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问内存了. 效率就⼤⼤提⾼了.
那么接下来问题⼜来了, 既然访问寄存器速度这么快, 还要内存⼲啥??
答案就是⼀个字: 贵
值的⼀提的是, 快和慢都是相对的. CPU 访问寄存器速度远远快于内存, 但是内存的访问速度⼜远远快于硬盘.
对应的, CPU 的价格最贵, 内存次之, 硬盘最便宜.
- 指令重排序
什么是代码重排序?
⼀段代码是这样的:
- 去前台取下 U 盘
- 去教室写 10 分钟作业
- 去前台取下快递
如果是在单线程情况下,JVM、CPU指令集会对其进⾏优化,⽐如,按 1->3->2的⽅式执⾏,也是没问题,可以少跑⼀次前台。这种叫做指令重排序
编译器对于指令重排序的前提是 "保持逻辑不发⽣变化". 这⼀点在单线程环境下⽐较容易判断, 但是在多线程环境下就没那么容易了, 多线程的代码执⾏复杂程度更⾼, 编译器很难在编译阶段对代码的执⾏效果进⾏预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价.
重排序是⼀个⽐较复杂的话题, 涉及到 CPU 以及编译器的⼀些底层⼯作原理, 此处不做过多讨论
4 解决之前的线程不安全问题
package Thread.ThreadUnsecurity;
public class sloveResolutuon {
public static int count=0;
public static void main(String[] args) throws InterruptedException {
Object locker=new Object();
Thread thread1=new Thread(()->{
for (int i = 0; i < 50000; i++) {
synchronized (locker){
count++;
}
}
});
Thread thread2=new Thread(()->{
for (int i = 0; i < 50000; i++) {
synchronized (locker){
count++;
}
}
});
thread1.start();
thread2.start();
//防止还没自增完成就开始打印
thread1.join();
thread2.join();
System.out.println(count);// 预期结果应该是 10w
}
}
二. synchronized 关键字 - 监视器锁 monitor lock
1.synchronized 的特性
a.互斥
synchronized 会起到互斥效果, 某个线程执⾏到某个对象的 synchronized 中时, 其他线程如果也执⾏到同⼀个对象 synchronized 就会阻塞等待.
- 进⼊ synchronized 修饰的代码块, 相当于 加锁
- 退出 synchronized 修饰的代码块, 相当于 解锁
可以粗略理解成, 每个对象在内存中存储的时候, 都存有⼀块内存表⽰当前的 "锁定" 状态(类似于厕所的 "有⼈/⽆⼈").如果当前是 "⽆⼈" 状态, 那么就可以使⽤, 使⽤时需要设为 "有⼈" 状态.如果当前是 "有⼈" 状态, 那么其他⼈⽆法使⽤, 只能排队
理解 "阻塞等待".针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程,再来获取到这个锁.
- 上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的⼀部分⼯作.
- 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B ⽐ C 先来的, 但是 B 不⼀定就能获取到锁, ⽽是和 C 重新竞争, 并不遵守先来后到的规则.
b.可重⼊
synchronized 同步块对同⼀条线程来说是可重⼊的,不会出现⾃⼰把⾃⼰锁死的问题;
理解 "把⾃⼰锁死"
⼀个线程没有释放锁, 然后⼜尝试再次加锁.
// 第⼀次加锁, 加锁成功
lock();
// 第⼆次加锁, 锁已经被占⽤, 阻塞等待.
lock();
按照之前对于锁的设定, 第⼆次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第⼆ 个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想⼲了, 也就⽆法进⾏解锁操作. 这时候就会 死锁.
这样的锁称为 不可重⼊锁.
Java 中的 synchronized 是 可重⼊锁, 因此没有上⾯的问题.
for (int i = 0; i < 50000; i++) {
synchronized (locker){
synchronized (locker) {
count++;
}
}
}
在可重⼊锁的内部, 包含了 "线程持有者" 和 "计数器" 两个信息.
• 如果某个线程加锁的时候, 发现锁已经被⼈占⽤, 但是恰好占⽤的正是⾃⼰, 那么仍然可以继续获取到锁, 并让计数器⾃增.
• 解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)
2 synchronized 使⽤⽰例
synchronized 本质上要修改指定对象的 "对象头". 从使⽤⻆度来看, synchronized 也势必要搭配⼀个具体的对象来使⽤.
1) 修饰代码块: 明确指定锁哪个对象.
锁任意对象
package Thread.ThreadUnsecurity;
public class SychronizedDemo {
public Object locker=new Object();
public void method(){
synchronized (locker){
}
}
}
锁当前对象
public class SychronizedDemo {
public void method() {
synchronized (this) {
}
}
}
2) 直接修饰普通⽅法: 锁的 SynchronizedDemo 对象
public synchronized void method(){
}
3) 修饰静态⽅法: 锁的 SynchronizedDemo 类的对象
public synchronized static void method(){
}
两个线程分别尝试获取两把不同的锁, 不会产⽣竞争.
3.Java 标准库中的线程安全类
- ArrayList
- LinkedList
- HashMap
- TreeMap
- HashSet
- TreeSet
- StringBuilder
- Vector (不推荐使⽤)
- HashTable (不推荐使⽤)
- ConcurrentHashMap
- StringBuffer
StringBuffer 的核⼼⽅法都带有 synchronized .
- String
三. volatile 关键字
1.volatile 能保证内存可⻅性
volatile 修饰的变量, 能够保证 "内存可⻅性".
代码在写⼊ volatile 修饰的变量的时候,
- 改变线程⼯作内存中volatile变量副本的值
- 将改变后的副本的值从⼯作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候,
- 从主内存中读取volatile变量的最新值到线程的⼯作内存中
- 从⼯作内存中读取volatile变量的副本
前⾯我们讨论内存可⻅性时说了, 直接访问⼯作内存(实际是 CPU 的寄存器或者 CPU 的缓存), 速度⾮常快, 但是可能出现数据不⼀致的情况.
加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.
代码⽰例
在这个代码中
• 创建两个线程 t1 和 t2
• t1 中包含⼀个循环, 这个循环以 flag == 0 为循环条件.
• t2 中从键盘读⼊⼀个整数, 并把这个整数赋值给 flag.
• 预期当⽤⼾输⼊⾮ 0 的值的时候, t1 线程结束.
package Thread;
import java.util.Scanner;
public class Counte{
static class Counter {
public int flag = 0;
}
public static void main(String[] args) {
Counter counter = new Counter();
Thread t1 = new Thread(() -> {
while (counter.flag == 0) {
// do nothing
}
System.out.println("循环结束!");
});
Thread t2 = new Thread(() -> {
Scanner scanner = new Scanner(System.in);
System.out.println("输⼊⼀个整数:");
counter.flag = scanner.nextInt();
});
t1.start();
t2.start();
}
}
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环不会结束. (这显然是⼀个 bug) t1 读的是⾃⼰⼯作内存中的内容.
//当 t2 对 flag 变量进⾏修改, 此时 t1 感知不到 flag 的变化.
//如果给 flag 加上 volatile
static class Counter {
public volatile int flag = 0;
}
执⾏效果
当⽤⼾输⼊⾮0值时, t1 线程循环能够⽴即结束.
2.volatile 不保证原⼦性
volatile 和 synchronized 有着本质的区别. synchronized 能够保证原⼦性, volatile 保证的是内存可⻅性.
代码⽰例
这个是最初的演⽰线程安全的代码.
• 给 increase ⽅法去掉 synchronized
• 给 count 加上 volatile 关键字.
package Thread.ThreadUnsecurity;
public class test {
static class Counter {
volatile public int count = 0;
void increase() {
count++;
}
}
public static void main(String[] args) throws InterruptedException {
final Counter counter = new Counter();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(counter.count);
}
}
四.wait()和notify()
由于线程之间是抢占式执⾏的, 因此线程之间执⾏的先后顺序难以预知.
但是实际开发中有时候我们希望合理的协调多个线程之间的执⾏先后顺序.
球场上的每个运动员都是独⽴的 "执⾏流" , 可以认为是⼀个 "线程".
⽽完成⼀个具体的进攻得分动作, 则需要多个运动员相互配合, 按照⼀定的顺序执⾏⼀定的动作, 线程 1 先 "传球" , 线程2 才能 "扣篮".
完成这个协调⼯作, 主要涉及到三个⽅法
• wait() / wait(long timeout): 让当前线程进⼊等待状态.
• notify() / notifyAll(): 唤醒在当前对象上等待的线程.
注意: wait, notify, notifyAll 都是 Object 类的⽅法.
1.wait()⽅法
wait和join都是等,二者的不同之处是
- join要等另一个线程彻底执行完才能继续执行
- wait只要等到notify就可以继续执行
加锁的等待是不受控制的,因为不确定其他线程是否“加锁”
wait 做的事情:
• 使当前执⾏代码的线程进⾏等待. (把线程放到等待队列中)
• 释放当前的锁
• 满⾜⼀定条件时被唤醒, 重新尝试获取这个锁.
wait 要搭配 synchronized 来使⽤. 脱离 synchronized 使⽤ wait 会直接抛出异常.
wait 结束等待的条件:
• 其他线程调⽤该对象的 notify ⽅法.
• wait 等待时间超时 (wait ⽅法提供⼀个带有 timeout 参数的版本, 来指定等待时间).
• 其他线程调⽤该等待线程的 interrupted ⽅法, 导致 wait 抛出 InterruptedException 异常.
线程饥饿现象:
当多个线程竞争一把锁的时候,获取到锁的线程如果释放了,其他是哪个线程拿到锁?不确定(随机调度)
操作系统的调度是随机的.其他线程都属于在锁上阻塞等待,是阻塞状态.当前这个释放锁的线程,是就绪状态.这个线程有很大的概率能够再次拿到这个锁
代码⽰例: 观察wait()⽅法使⽤
改进:
public static void main(String[] args) throws InterruptedException {
Object object = new Object();
synchronized (object) {
System.out.println("等待中");
object.wait();
System.out.println("等待结束");
}
}
这样在执⾏到object.wait()之后就⼀直等待下去,那么程序肯定不能⼀直这么等待下去了。这个时候就需要使⽤到了另外⼀个⽅法,唤醒的⽅法notify()。
代码进入wait,就会先释放锁,并且阻塞等待
如果其他线程做完了必要的工作,调用notify唤醒这个wait线程
wait就会解除阻塞,重新获取到锁.继续执行并返回.
2.notify()⽅法
notify ⽅法是唤醒等待的线程.
• ⽅法notify()也要在同步⽅法或同步块中调⽤,该⽅法是⽤来通知那些可能等待该对象的对象锁的其它线程,对其发出通知notify,并使它们重新获取该对象的对象锁。
• 如果有多个线程等待,则有线程调度器随机挑选出⼀个呈 wait 状态的线程。(并没有 "先来后到")
• 在notify()⽅法后,当前线程不会⻢上释放该对象锁,要等到执⾏notify()⽅法的线程将程序执⾏
完,也就是退出同步代码块之后才会释放对象锁。
代码⽰例: 使⽤notify()⽅法唤醒线程
• 创建 WaitTask 类, 对应⼀个线程, run 内部循环调⽤ wait.
• 创建 NotifyTask 类, 对应另⼀个线程, 在 run 内部调⽤⼀次 notify
• 注意, WaitTask 和 NotifyTask 内部持有同⼀个 Object locker. WaitTask 和 NotifyTask 要想配合就
需要搭配同⼀个 Object.
package Thread.ThreadUnsecurity;
public class notifyTest {
static class WaitTask implements Runnable{
private Object locker;
public WaitTask(Object locker){
this.locker=locker;
}
@Override
public void run(){
synchronized (locker){
while (true){
try {
System.out.println("开始wait");
locker.wait();
System.out.println("wait结束");
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
}
}
}
static class NotifyTask implements Runnable{
private Object locker;
public NotifyTask(Object locker){
this.locker=locker;
}
@Override
public void run(){
synchronized (locker){
while (true){
System.out.println("开始notify");
locker.notify();
System.out.println("notify结束");
}
}
}
}
public static void main(String[] args) throws InterruptedException {
Object locker=new Object();
Thread thread1=new Thread(new WaitTask(locker));
Thread thread2=new Thread(new NotifyTask(locker));
thread1.start();
Thread.sleep(1000);
thread2.start();
}
}
3.notifyAll()⽅法
notify⽅法只是唤醒某⼀个等待线程. 使⽤notifyAll⽅法可以⼀次唤醒所有的等待线程.
范例:使⽤notifyAll()⽅法唤醒所有等待线程, 在上⾯的代码基础上做出修改.
• 创建 3 个 WaitTask 实例. 1 个 NotifyTask 实例.
package Thread.ThreadUnsecurity;
public class notifyTest {
static class WaitTask implements Runnable{
private Object locker;
public WaitTask(Object locker){
this.locker=locker;
}
@Override
public void run(){
synchronized (locker){
while (true){
try {
System.out.println("开始wait");
locker.wait();
System.out.println("wait结束");
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
}
}
}
static class NotifyTask implements Runnable{
private Object locker;
public NotifyTask(Object locker){
this.locker=locker;
}
@Override
public void run(){
synchronized (locker){
System.out.println("开始notify");
locker.notify();
System.out.println("notify结束");
}
}
}
public static void main(String[] args) throws InterruptedException {
Object locker = new Object();
Thread t1 = new Thread(new WaitTask(locker));
Thread t3 = new Thread(new WaitTask(locker));
Thread t4 = new Thread(new WaitTask(locker));
Thread t2 = new Thread(new NotifyTask(locker));
t1.start();
t3.start();
t4.start();
Thread.sleep(1000);
t2.start();
}
}
此时可以看到, 调⽤ notify 只能唤醒⼀个线程.
static class NotifyTask implements Runnable{
private Object locker;
public NotifyTask(Object locker){
this.locker=locker;
}
@Override
public void run(){
synchronized (locker){
System.out.println("开始notify");
locker.notifyAll();
System.out.println("notify结束");
}
}
}
此时可以看到, 调⽤ notifyAll 能同时唤醒 3 个wait 中的线程
注意: 虽然是同时唤醒 3 个线程, 但是这 3 个线程需要竞争锁. 所以并不是同时执⾏, ⽽仍然是有先有后的执⾏.
理解 notify 和 notifyAll
- notify 只唤醒等待队列中的⼀个线程. 其他线程还是乖乖等着
- notifyAll ⼀下全都唤醒, 需要这些线程重新竞争锁
4.wait 和 sleep 的对⽐(⾯试题)
其实理论上 wait 和 sleep 完全是没有可⽐性的,因为⼀个是⽤于线程之间的通信的,⼀个是让线程阻塞⼀段时间,唯⼀的相同点就是都可以让线程放弃执⾏⼀段时间.
当然为了⾯试的⽬的,我们还是总结下:
1. wait 需要搭配 synchronized 使⽤. sleep 不需要.
2. wait 是 Object 的⽅法 ,sleep 是 Thread 的静态⽅法.
五. 总结-保证线程安全的思路
- 使⽤没有共享资源的模型
- 适⽤共享资源只读,不写的模型
- 不需要写共享资源的模型
- 使⽤不可变对象
- 直⾯线程安全(重点)
- 保证原⼦性
- 保证顺序性
- 保证可⻅性
六. 对⽐线程和进程
1 线程的优点
- 创建⼀个新线程的代价要⽐创建⼀个新进程⼩得多
- 与进程之间的切换相⽐,线程之间的切换需要操作系统做的⼯作要少很多
- 线程占⽤的资源要⽐进程少很多
- 能充分利⽤多处理器的可并⾏数量
- 在等待慢速I/O操作结束的同时,程序可执⾏其他的计算任务
- 计算密集型应⽤,为了能在多处理器系统上运⾏,将计算分解到多个线程中实现
- I/O密集型应⽤,为了提⾼性能,将I/O操作重叠。线程可以同时等待不同的I/O操作。
2 进程与线程的区别
- 进程是系统进⾏资源分配和调度的⼀个独⽴单位,线程是程序执⾏的最⼩单位。
- 进程有⾃⼰的内存地址空间,线程只独享指令流执⾏的必要资源,如寄存器和栈。
- 由于同⼀进程的各线程间共享内存和⽂件资源,可以不通过内核进⾏直接通信。
- 线程的创建、切换及终⽌效率更⾼。