【JavaEE初阶】死锁问题

最新推荐文章于 2024-09-30 23:20:02 发布

Hannn~

最新推荐文章于 2024-09-30 23:20:02 发布

阅读量1.3k

点赞数 56

分类专栏： JavaEE 文章标签： java java-ee 死锁

本文链接：https://blog.csdn.net/m0_61876562/article/details/134692032

版权

JavaEE 专栏收录该内容

19 篇文章 1 订阅

订阅专栏

死锁，是多线程代码中的一类经典问题。我们知道加锁是能解决线程安全问题的，但是如果加锁的方式不当，就可能产生死锁。

一、死锁的三种典型场景

1、一个线程，一把锁

对于不可重入锁来说：

一个线程没有释放锁, 然后又尝试再次加锁。
// 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待.
lock();
按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第二个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无法进行解锁操作. 这时候就会死锁。

对于这种情况就是，如果锁是不可重入的锁，并且一个线程对这把锁加锁两次，就会出现死锁。

2、两个线程，两把锁

假设有两个线程，线程1获取到锁A（对A对象加锁），线程2获取到锁B（对B对象加锁），接下来，线程1尝试获取锁B，线程2尝试获取锁A，这时就会出现死锁。

示例代码如下：

public class ThreadDemo1 {
    public static void main(String[] args) {
        Object A = new Object();
        Object B = new Object();
        Thread t1 = new Thread(()->{
            synchronized (A) {
                //sleep一下，让t2能拿到B
                try {
                    Thread.sleep(1000);
                }catch (InterruptedException e) {
                    e.printStackTrace();
                }

                //在持有A的情况下，对B加锁
                synchronized (B) {
                    System.out.println("t1拿到了两把锁");
                }
            }
        });
        Thread t2 = new Thread(()->{
            synchronized (B) {
                //sleep一下，让t1能拿到A
                try {
                    Thread.sleep(1000);
                }catch (InterruptedException e) {
                    e.printStackTrace();
                }

                //在持有B的情况下，对A加锁
                synchronized (A) {
                    System.out.println("t2拿到了两把锁");
                }
            }
        });

        //死锁，一直僵持着，若让t2先对A加锁，再对B加锁，就可避免死锁
        t1.start();
        t2.start();

    }
}

这时候发生死锁，线程就“卡住了”，无法继续工作（死锁属于程序中最严重的一类bug），可见这个代码不会运行出任何结果，如图：

我们可以通过 jconsole 来观察这两个线程此时的状态：

这两个线程都处于死锁阻塞的状态。

如果此时约定加锁顺序，让线程2也先对A加锁，后对B加锁，这样死锁就可以解决。

3、N个线程，M把锁

这里用一个典型的例子来描述，哲学家就餐问题。

哲学家就餐问题：该问题描述的是五个哲学家共用一张圆桌，分别坐在周围的五张椅子上，在圆桌上有五个碗和五只筷子，他们的生活方式是交替的进行思考和进餐。平时，一个哲学家进行思考，饥饿时便试图取用其左右最靠近他的筷子，只有在他拿到两只筷子时才能进餐。进餐完毕，放下筷子继续思考。

这个问题中，五个哲学家就相当于五个线程，五只筷子就相当于五把锁。

在绝大多数情况下，这个问题是可以正常工作的。但有一些极端的特殊情况，这时会产生死锁。假如同一时刻，所有的哲学家都想吃面条，同时拿起了自己左边的筷子，这个时候，他们继续尝试拿起右边的筷子，这时就拿不到了，因为被别人给拿着了。此时，哲学家们都等待旁边的人释放筷子，但由于所有的哲学家都不想放下自己手中的筷子，这时就产生死锁了，谁都吃不到面条。

如何解决死锁呢？我们先来看一下产生死锁的四个必要条件：

互斥使用：获取锁的过程是互斥的，一个线程拿到了这把锁，另一个线程也想获取，就要阻塞等待。
不可抢占：一个线程拿到这把锁后，只能主动解锁，不能让别的线程强行把锁抢走。
请求保持：一个线程拿到了一把锁后，会持有这把锁，像持有锁A的情况下，尝试获取锁B。
循环等待/环路等待：像哲学家问题一样，1号哲学家等待2号哲学家释放筷子，2号哲学家等待3号哲学家释放筷子……

解决死锁的问题，核心思路就是破坏上述的必要条件，只要破坏一个就可以解决死锁。

对于互斥使用和不可抢占，这是锁的最基本特性，不太好破坏；对于请求保持（代码结构方面），是否能破坏，要看实际需求；对于循环等待（代码结构方面），是最容易破坏的。

解决上述哲学家问题死锁的情况，其实有很多方案：

引入额外的筷子
去掉一个线程（哲学家）
引入计数器，限制最多同时有几个哲学家进餐
引入加锁顺序的规则
银行家算法（操作系统中的重要内容）

1、2、3方案，虽然不复杂，但是普适性不高，有时候用不了；3方案普适性高。

我们这里用一下3方案（引入加锁顺序的规则）来解决哲学家死锁的问题，只要指定一定的规则，就可以有效避免循环等待，从而破坏循环等待这个必要条件。指定加锁顺序，针对五只筷子，进行编号，约定每个哲学家获取筷子的时候，一定要先拿自己左右两边编号较小的筷子，拿到之后，再拿编号较大的。如图（假设2号哲学家先拿到1号筷子）：

5号哲学家拿到5号筷子后，就可以进餐了，吃完之后，放下4号和5号筷子；接着，4号哲学家就可以拿到4号筷子，进餐，吃完之后，放下3号和4号筷子；接着，3号哲学家就可以拿到3号筷子，进餐，吃完之后，放下2号和3号筷子……最终，1号哲学家就可以拿到1号筷子和5号筷子，进餐。这样每个哲学家都可以吃到面条，死锁问题也就解决了。