【JavaEE初阶】死锁问题

目录

一、死锁的三种典型场景

1、一个线程,一把锁

2、两个线程,两把锁

3、N个线程,M把锁


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

一、死锁的三种典型场景

1、一个线程,一把锁

对于不可重入锁 来说**:**

一个线程没有释放锁, 然后又尝试再次加锁。

// 第一次加锁, 加锁成功

lock();

// 第二次加锁, 锁已经被占用, 阻塞等待.

lock();

按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第二个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无法进行解锁操作. 这时候就会死锁。

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

2、两个线程,两把锁

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

示例代码如下:

java 复制代码
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. 引入计数器,限制最多同时有几个哲学家进餐
  4. 引入加锁顺序的规则
  5. 银行家算法(操作系统中的重要内容)

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

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

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

相关推荐
qq_3273427318 分钟前
Java实现离线身份证号码OCR识别
java·开发语言
阿龟在奔跑2 小时前
引用类型的局部变量线程安全问题分析——以多线程对方法局部变量List类型对象实例的add、remove操作为例
java·jvm·安全·list
飞滕人生TYF2 小时前
m个数 生成n个数的所有组合 详解
java·递归
代码小鑫2 小时前
A043-基于Spring Boot的秒杀系统设计与实现
java·开发语言·数据库·spring boot·后端·spring·毕业设计
真心喜欢你吖2 小时前
SpringBoot与MongoDB深度整合及应用案例
java·spring boot·后端·mongodb·spring
激流丶2 小时前
【Kafka 实战】Kafka 如何保证消息的顺序性?
java·后端·kafka
周全全2 小时前
Spring Boot + Vue 基于 RSA 的用户身份认证加密机制实现
java·vue.js·spring boot·安全·php
uzong3 小时前
一个 IDEA 老鸟的 DEBUG 私货之多线程调试
java·后端
AiFlutter3 小时前
Java实现简单的搜索引擎
java·搜索引擎·mybatis
飞升不如收破烂~3 小时前
Spring boot常用注解和作用
java·spring boot·后端