【多线程】死锁

news2024/11/14 22:32:16

🥰🥰🥰来都来了，不妨点个关注叭！
👉博客主页：欢迎各位大佬!👈

在这里插入图片描述

文章目录

1. 死锁的三种情况
- 1.1 一个线程一把锁（同一个线程给同一个对象加两次锁的情况）
- 1.2 两个线程两把锁
- 1.3 N个线程M把锁
2. 造成死锁的 4 个必要条件
3. 如何避免死锁？
- 3.1 加锁顺序
- 3.2 资源分配策略
- 3.3 设置锁的超时机制
- 3.4 死锁检测与恢复
- 3.5 避免共享资源

在常见的锁策略这期内容中，介绍了几种常见的锁策略，其中，提到了"死锁"这一概念，本期内容具体讲解死锁~

1. 死锁的三种情况

1.1 一个线程一把锁（同一个线程给同一个对象加两次锁的情况）

一个线程一把锁的这个情况下，可重入锁没事，不可重入锁发生死锁！

class BlockingQueue {
    synchronized void put(int elem) {
        this.size();
        ...
    }
    
    synchronized int size() {
        ...
    }
}

在上述代码中，put()方法和size()方法这两个方法都给同一个锁对象 this 加锁，通过上述代码，可以看到，在 put()方法中调用了size()方法，进入put()方法的时候，对 this 对象加锁了，而在put()中调用size()时，又对 this 对象加了锁，这在日常开发中，很常见，实际上，这个情况并不会造成死锁，因为 synchronized 是可重入锁

常见的锁策略介绍了可重入锁和不可重入锁，在这里，再简单介绍一下：

可重入锁：允许同一个线程多次获取同一把锁，如果一个锁，在一个线程中，连续对锁，加锁两次，不死锁，即可重入锁
不可重入锁：如果一个锁，在一个线程中连续对锁，加锁两次，死锁，则是不可重入锁

1.2 两个线程两把锁

两个线程两把锁的这个情况下，即使是可重入锁，也可能会死锁，比如这个情况，如下图：

在这里插入图片描述
t1 线程和 t2 线程并发执行，t1 线程先对 locker1 加锁，t2 线程先对 locker2 加锁，t1 线程继续执行，此时又要对 locker2 加锁，但是必须等待 t2 线程先释放 locker2，t2 线程继续执行，又要对 locker1 加锁，但是必须等待 t1 线程先释放 locker1，这样一来，就发生了死锁的情况

举一个生活中的栗子，这就好比在疫情期间，你没戴口罩准备去药店买口罩的时候，药店却让你必须戴口罩才能进入药店，这样就形成一个死锁的情况~

1.3 N个线程M把锁

线程的数量和锁的数量变多了后，更加复杂之后，就更容易造成死锁的情况~

这就涉及到一个著名的问题 —— “哲学家就餐问题” ：5根筷子分别放在5位哲学家两两之间，哲学家想要吃面条，必须同时拿到左边的一根筷子和右边的一根筷子，只有一根筷子无法吃面条

这五个哲学家，
1）随机的进行去吃面条（拿筷子）和思考人生（放下筷子）
2）如果哲学家想要拿筷子，被别人占用了，就会等待，等的过程中不会放下手中已经拿到的筷子（非常地固执~）

在这里插入图片描述
可以看到，如果此时五位哲学家同时拿起左手边的筷子，他们还想拿起右边的筷子，但是筷子已经被旁边的哲学家左手边拿起来了，只能进行阻塞等待，就死锁了，即一个线程如果想要两次加锁，已经加了一个，另一个被抢走了，它就会一直等待，同时，占用着第一次加的锁

2. 造成死锁的 4 个必要条件

互斥使用：即一个线程拿到一把锁之后，这个资源被这个线程占有时，另一个线程不能使用【锁的基本特点】
不可抢占：即一个线程拿到锁，只能自己主动释放，不能被其它线程强行占有，资源请求者不能强制从资源占有者手中夺取资源（不能挖墙脚呀！）【锁的基本特点】
请求和保持：即资源请求者在请求其它资源的同时，保持对原有资源的占有（典型的吃着碗里的看着锅里的）【代码的特点】
循环等待：即存在一个等待队列，P1 占有 P2 资源，P2 占有 P3 资源，P3 占有 P4 资源，P4 资源占有 P1资源…，形成逻辑依赖循环的等待环路（钥匙锁车里了，车钥匙又锁家里了）（上述哲学家中，哲学家1等待5，2等待1，3等待2，4等待3，而5又等待1）【代码的特点】

3. 如何避免死锁？

避免死锁有很多种方法，这里介绍五种（重点介绍第一种：加锁顺序）

3.1 加锁顺序

死锁是一个比较严重的 BUG，实践中如何避免死锁呢？

当造成死锁的4个必要条件都成立时，形成死锁，在死锁的情况下，如果打破上述任何一个条件，死锁情况就可以避免，其中一个简单有效的办法是，破解循环等待这个条件

【具体操作】针对锁进行编号，如果需要同时获取多把锁，约定加锁顺序，务必是先对小的编号加锁，后对大的编号加锁

1）针对N个线程M把锁情况

约定：每个哲学家只能先获取左手和右手中编号较小的筷子，2 号哲学家先获取1 号筷子，剩下的哲学家也依次获取左右手之间编号较小的筷子，轮到最后一位 1 号哲学家的时候，由于 1 号筷子已经被占用，他就无法获取 1 号筷子，从而进入阻塞等待，这样哲学家还想拿一根筷子的时候，5 号哲学家可以拿到编号5的筷子，吃完面条后，将编号4和5的筷子放下，依次的3号、2号哲学家也能完成吃面的任务，等到 2 号哲学家放下筷子，1 号哲学家就可以拿到 1 号筷子和 5 号筷子，从而结束阻塞等待，不会形成死锁情况，如下图：

在这里插入图片描述
因此，只要约定了加锁顺序，循环等待条件就会自然破除，死锁的情况也就可以避免，体现在代码中，就是只要是一个线程中要加多把锁，就一定需要注意加锁顺序，可以约定每次加锁的时候都先给编号小的加锁，后给编号大的加锁，并且所有的线程都遵循这个顺序即可

2）针对两个线程两把锁情况

只要每次加锁的时候都先给 locker1 加锁，后给 locker2 加锁即可，将线程加锁顺序固定下来，可以破除循环等待，如下图所示：

在这里插入图片描述

3.2 资源分配策略

可以使用 银行家算法 等资源分配策略，主要用于多道程序系统中避免死锁的发生，银行家算法通过预测资源分配后的系统状态，来避免系统进入不安全状态，从而防止死锁的发生，其本质是对资源更合理的分配，但是本身这个算法比较复杂，实现这个算法本身还可能引入额外的 BUG，因此，不适合实际开发中使用（这里不详细展开）