文章目录
- 一. 引出死锁
- 二. 可重用锁
- 三. 死锁的三种典型场景
- 四. 死锁产生的四个必要条件(面试题)
- 1. 锁具有互斥特性
- 2. 锁不可抢占(不可被剥夺)
- 3. 请求和保持
- 4. 循环等待
- 五. 避免死锁问题
一. 引出死锁
class Counter{
private int count;
public void add(){
synchronized(this){
count++;
}
}
public int get(){
return count;
}
}
public class Demo15 {
public static void main(String[] args) throws InterruptedException {
Counter counter = new Counter();
Thread t1 = new Thread(() -> {
for(int i = 0; i < 50000; i++){
synchronized(counter){
counter.add();
}
}
});
t1.start();
t1.join();
System.out.println("count = " + counter.get());
}
}
上述代码, 我们在counter对象调用add时加了counter锁, 同时在add方法中也加counter锁, 这时我们就对同一块代码加了两层锁, 形成了锁嵌套锁的结构
思考:
当我们第一次对count上锁时, 是肯定会成功的
当第二次尝试加count锁时, 此时这个锁已经是被锁住的状态
按照之前的理解, 对一个已经被锁住的对象再进行加锁时, 就会出现阻塞等待
等待count锁被释放, 才能再进行加锁
但是,
要想获取到第二层锁, 就需要执行完第一层锁的大括号
要想执行完第一层锁的大括号, 就需要先获取第二层锁
这种现象就叫死锁
二. 可重用锁
运行上述代码:
发现并没有发生问题, 原因在于:
synchronized这个关键字, JVM在内部进行了特殊的处理
每个锁对象, 都会记录下来当前是哪个线程持有了这个锁,
当针对一个对象加锁操作时, 先会判定一下, 当前尝试加锁的线程, 是否是持有这个锁的状态,
如果没有持有这个锁, 则需要等待其他线程解锁
如果持有这个锁, 则直接放行, 就会加一遍相同的锁!!
这样的机制, 叫做==“可重用锁”==, 目的就是为了避免程序员搞出死锁
注意: 这是java锁synchronized特殊的地方, 如果是c++ / Python的锁, 嵌套锁就会发生死锁!!
三. 死锁的三种典型场景
场景一: 一个线程针对一个对象, 连续加锁(不可重入锁)两次
就是上述的问题:
如果是不可重入锁, 并且一个线程针对一个对象, 连续加锁两次, 就会引起死锁
解决方法就是引入不可重入锁
场景二: 两个线程两把锁
现在又线程1和线程2, 有两把锁A和B
两个线程先分别获取两把锁, 线程1获取A, 线程2获取B, 分别拿到锁后, 在释放之前, 再次尝试获取对方的锁
public class Demo16 {
public static void main(String[] args) {
Object locker1 = new Object();
Object locker2 = new Object();
Thread t1 = new Thread(() -> {
synchronized (locker1){
try {
Thread.sleep(1000);//让t1等待一下t2启动, 获取locker2
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
synchronized (locker2){
System.out.println("t1获取了两把锁");
}
}
});
Thread t2 = new Thread(() -> {
synchronized (locker2){
synchronized (locker1){
System.out.println("t2获取了两把锁");
}
}
});
t1.start();
t2.start();
}
}
此时运行发现:
代码正在运行, 但是什么也没打印, 说明t1t2都没拿到两把锁
t1等待t2释放locker2, t2等待t1释放locker1, 就发生了死锁
此时可以通过jconsole工具观察线程状态:
t1:
t2:
都是BLOCKED状态
场景三: N个线程, M把锁
随着线程数目 / 锁的个数增加, 此时情况就更复杂了, 就更容易出现死锁了
一个经典问题: 哲学家进餐问题
一张圆桌上面一碗面条, 假设共5个哲学家, 每个哲学家之间都有一根筷子, 哲学家可以选择:
1)思考人生(放下筷子)
2)吃面条, (此时需要拿起左右两根筷子, 才能吃面条)
每个哲学家啥时候吃面条, 啥时候思考人生, 这都是不确定的, 模拟线程抢占式执行
大多数情况下, 都是可以正常运行的, 只需要等待即可
但是如果出现极端情况, 就会出现问题:
如果同一时刻, 所有的哲学家都想要吃面条, 都同时拿起了左边的筷子, 那么当想要拿起右边筷子的时候, 就会发生阻塞等待, 每一个人都在等待右边的人放下筷子, 此时就会发生死锁!
四. 死锁产生的四个必要条件(面试题)
死锁, 是一个非常严重的问题!!
死锁的发生就会导致线程被卡住, 没法继续执行
同时, 死锁的产生是随机性的, 可能测试一万次都没有发生, 但是无法保证第一万零一次是否会发生死锁
死锁产生的四个必要条件:
(必要条件:缺一不可, 任何一个死锁场景,都必须具备以下四点!!!)
1. 锁具有互斥特性
这是锁的基本特点, 一个线程拿到锁后, 其他线程就得阻塞等待
(锁的基本特点)
2. 锁不可抢占(不可被剥夺)
一个线程拿到锁后, 除非自己主动释放, 别人是没法抢占的
(锁的基本特点)
3. 请求和保持
一个线程拿到一把锁后, 在不释放这个锁的前提下, 再尝试获取其他锁
(代码结构)
4. 循环等待
多个线程获取多个锁的过程中, 出现了循环等待, 如A等B, B等A
(代码结构)
五. 避免死锁问题
根据上面死锁产生的条件, 分析如何避免死锁
条件一和条件二使我们无法改变的
条件三我们可以尽量避免不让锁嵌套获取, 但是有的时候为了线程安全, 我们又必须要嵌套
条件四, 我们可以破除循环等待, 技术出现嵌套, 也不会死锁
那么我们就可以通过约定加锁顺序来避免死锁
例如上述代码:
我们约定好, 只能先加locker1, 再加locker2
这样就不会出现死锁了, t2只能等待t1释放locker1后, 才能继续执行
再看哲学家就餐问题, 如果我们给每根筷子编号, 当哲学家拿筷子的时候, 只能拿编号小的筷子, 此时, 当5个人同时拿起筷子:
当代码中, 确实需要用到多个线程获取多把锁, 一定要约定好加锁顺序, 就可以有效避免死锁了
