【线程安全】死锁问题及解决方案

1. 什么是死锁

比如上一次讲到 synchronized 的时候，一个线程，对同一个对象连续加锁两次，如果出现阻塞等待，代表这个锁是不可重入锁，这样的线程，也就称为死锁！

一旦程序进入死锁了就会导致线程僵住了，无法继续执行后续的工作了，程序也就出现了严重的 BUG！

而死锁这样的情况是很隐蔽的，在开发阶段，不经意间就可能出现死锁的状态！

2. 死锁的三个典型情况

2.1 一个线程一把锁

一个线程，对同一个对象，重复加锁两次，如果不支持可重入，即会出现死锁现象，但是在 Java 中，synchronized 和 ReentarntLock(后面讲) 都是支持可重入的！

所以在 Java 中，也就不会出现这样的情况，但不排除在其他语言会出现这种情况。

2.2 两个线程两把锁

举一个生活中的例子来让大家更好的理解：

有一天张三和小美是俩社恐人员，他俩去吃牛排，由于小美吃不了太多，于是他俩就点了一份牛排，服务员只给了一个刀和叉，此时张三一把夺过刀，小美一把夺过叉，此时小美对张三说，你先把刀给我，我吃一口就给你，张三说不行，你先把叉子给我，我吃一口再给你，于是这样她俩谁都不让着谁，导致谁都吃不上牛排了！

如果把上述例子放在编程中，就比如张三和小美是两个线程，张三获取到对象A的锁，小美获取到对象 B 的锁，但是他俩还尝试获取对方的锁！

用代码表示如下：

public static void main(String[] args) {
    Object knife = new Object(); //刀
    Object fork = new Object(); //叉
    Thread t1 = new Thread(() -> {
        synchronized (knife) {
            System.out.println("张三拿到刀了!");
            synchronized (fork) {
                System.out.println("张三刀和叉都拿到了!吃牛排!");
            }
        }
    });
    Thread t2 = new Thread(() -> {
        synchronized (fork) {
            System.out.println("小美拿到叉了!");
            synchronized (knife) {
                System.out.println("小美刀和叉都拿到了!吃牛排!");
            }
        }
    });
    t1.start();
    t2.start();
}

打印结果：

此时就发现，代码僵住了，其实也就是 t1 在等 t2 释放锁，而 t2 也在等 t1 释放锁，此时两个线程都无休止的阻塞等待下去了，最终导致，张三拿不到刀叉，小美也拿不到刀叉！都不吃成牛排了！

上述代码的写法是有小概率让张三同时拿到刀和叉的，这个取决于 CPU 的调度。

这里可以通过 jconsole 工具来查看一下线程的情况：

这里发现线程进入了 BLOCKED 状态，前面讲解线程状态的时候说过，BLOCKED 状态是等待锁时产生的状态，当然也可以给上述代码添加获取线程状态的方法，也能发现是 BLOCKED 状态：

Thread.sleep(1000); // 保证进入阻塞状态
System.out.println(t1.getState()); // 查看t1线程状态
System.out.println(t2.getState()); // 查看t2线程状态

2.3 多个线程多把锁

多个线程多把的情况跟上述 2.2 的情况差不多，相当于是 2.2 的一般情况！

在很多资料上有一个典型的案例 "哲学家就餐问题" ！

有一个桌子，围着一圈哲学家，每个哲学家面前放着一碗面，哲学家两两之间放一只筷子，而桌子上的哲学家只会做两件事：吃面(获取到锁，执行后续代码)或者思考人生(阻塞等待)。

当哲学家吃面的时候，就会拿起左右手的筷子(先拿左边，再拿右边)，当哲学家思考人生的时候，就会放下左右手的筷子。

如果哲学家拿到两根筷子了，就会吃面，没拿到就会思考人生！

极端情况来了！如果五个哲学家同时都拿起左手边的筷子，接着每个人都去拿自己右手边的筷子，发现右边的筷子都被别人拿走了！都要等右边的哲学家把筷子放下，此时就僵住了！由于哲学家们互不相让，此时也就形成了死锁的现象。

---

3. 如何避免死锁

3.1 产生死锁的四个必要条件

互斥使用：当 t1 线程拿到了锁，t2 如果也想拿，必须等着，等 t1 释放了(锁的基本特性)

不可抢占：t1 拿到了锁，必须由 t1 主动释放，t2 不能强行获取锁！

保持和请求：t1 拿到了锁 A，再拿到了 B 的锁，此时 A 这把锁还是保持的(不会因为获取到了锁 B 就把 锁 A 给释放了)

循环等待：当 t1 尝试获取锁A和B，t2也尝试获取锁B和A，如果 t1 获取到锁A，t2 获取到锁B，此时 t1 就会等待 t2 释放锁B，而 t2 也会等待 t1 释放锁 A

所以只要打破这四条的任意一条，就能让死锁消失，但前三条对于 synchronized 来说，都是基本的特性，修改不了，而循环等待上述唯一一个和代码结构相关的，也是咱们可以控制的！

所以解决死锁最简单可靠的办法，就是打破循环等待！

3.2 打破循环等待

如何打破循环等待呢？就比如上述张三和小美吃牛排的问题！

张三一把夺过刀，小美一把夺过叉，于是张三想了个公平的办法，对小美说："这样的情况，我们都吃不到牛排，我们做个约定吧，把刀叉一起放着，数到一就一起抢，但是有一个抢的顺序，只能先刀在抢叉"。

这就好比对刀和叉进行了编号，约定好，想要拿刀叉，可以，但是必须先拿刀，后拿叉！

于是张三数到一，一瞬间张三抢到了刀，此时小美没有抢到刀，由于前面的约定，小美只能等张三放下刀了，于是张三就顺利吃到了牛排！

代码实现：

public static void main(String[] args) throws InterruptedException {
    Object knife = new Object(); //刀
    Object fork = new Object(); //叉
    Thread t1 = new Thread(() -> {
        // 先对刀加锁, 才能对叉加锁
        synchronized (knife) {
            System.out.println("张三拿到刀了!");
            synchronized (fork) {
                System.out.println("张三刀和叉都拿到了!吃牛排!");
            }
        }
    });
    Thread t2 = new Thread(() -> {
        // 先对刀加锁, 才能对叉加锁
        synchronized (knife) {
            System.out.println("小美拿到刀了!");
            synchronized (fork) {
                System.out.println("小美刀和叉都拿到了!吃牛排!");
            }
        }
    });
    t1.start();
    t2.start();
}

打印结果：

做了约定之后(对锁编号)，此时死锁的问题就迎刃而解了！

那么对于哲学家吃面的问题，也是如此，对每根筷子进行编号，约定好，只能先拿左右手编号小的筷子，再拿编号大的筷子。

此时这样一来，总有一个人拿不到筷子，那么上述情况，拿到编号为 4 筷子的哲学家就能拿编号为 5 筷子吃面了，吃完了放下两支筷子，接着右手边拿到 3 筷子的哲学家就拿起放下的 编号4 筷子进行吃面了，以此类推.....

本质上我们这里讲的避免死锁的方案，就是约定加锁顺序！约定顺序后，死锁的问题就解决了！也就打破了第四点的循环等待！

其实还有一种算法，银行家算法， 但实际开发中不推荐使用，比起上述讲的办法银行家算法更复杂，也更容易出错，所以更推荐上述约定顺序的方法！

如果对银行家算法感兴趣的，可以自行查阅下相关资料！

---

下期预告：【多线程】volatile 关键字