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

1. 什么是死锁

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

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

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

2. 死锁的三个典型情况

2.1 一个线程一把锁

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

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

2.2 两个线程两把锁

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

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

【线程安全】死锁问题及解决方案_第1张图片

如果把上述例子放在编程中,就比如张三和小美是两个线程,张三获取到对象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();
}

打印结果:

【线程安全】死锁问题及解决方案_第2张图片

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

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

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

【线程安全】死锁问题及解决方案_第3张图片

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


Thread.sleep(1000); // 保证进入阻塞状态
System.out.println(t1.getState()); // 查看t1线程状态
System.out.println(t2.getState()); // 查看t2线程状态
【线程安全】死锁问题及解决方案_第4张图片

2.3 多个线程多把锁

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

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

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

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

【线程安全】死锁问题及解决方案_第5张图片

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

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


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();
}

打印结果:

【线程安全】死锁问题及解决方案_第6张图片

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

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

【线程安全】死锁问题及解决方案_第7张图片

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

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

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

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


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

你可能感兴趣的:(多线程从入门到精通(暂时限免),jvm,死锁,多线程,线程安全)