死锁问题【javaEE初阶】

什么是死锁?
        所谓死锁,是指多个进程在运行过程中因争夺资源而造成的一种僵局,当进程处于这种僵持状态时,若无外力作用,它们都将无法再向前推进。 因此我们举个例子来描述,如果此时有一个线程A,按照先锁a再获得锁b的的顺序获得锁,而在此同时又有另外一个线程B,按照先锁b再锁a的顺序获得锁。 

一、"死锁"出现的典型场景

(一)一个线程一把锁连续加锁两次,如果锁是不可重入锁,就会死锁

一个线程一把锁,这个就是之前所介绍的 可重入锁 

线程A 针对锁1 连续加锁两次,就构成了死锁 !

第一次加锁 加锁成功,第二次加锁 就需要第一次的锁释放,于是就阻塞等待;

但是,第一次加锁释放,就得依赖第二次加锁成功;

于是,"死锁" 就出现了!!!

(二)两个线程两把锁,相互获取对方锁 

此时,不管是不是可重入锁,都会造成 "死锁" 问题 !

可以用一个例子来说明情况:

假设 甲同学 和 乙同学 在一起

甲同学 吃饺子喜欢蘸酱油,乙同学 吃饺子喜欢蘸醋,由于在一起了,生活习性都受到了彼此的影响,两位同学吃饺子的时候 喜欢都蘸上一点了

有一天,吃饺子的时候,甲同学拿起了酱油,乙同学拿起了醋 ~

甲同学说:"你把醋给我,我用完了都给你";乙同学说:"你把酱油给我,我用完了就把醋给你" ~

此时,两者相持不下,这就造成了 "死锁" 问题 

此时,甲同学 和 乙同学 就可以看成是两个线程,酱油和醋 就可以看成是两把锁 

线程1 获取到锁A,线程2 获取到锁B;

线程1 尝试获取锁B(需要线程2 释放锁B) ,线程2 尝试获取到锁A(需要线程1 释放锁A);

在这种情况下,逻辑上就构成了循环,就构成了 "死锁" ~ 

import java.util.concurrent.TimeUnit;

public class Main {
    public static void main(String[] args) {
        Object lock1 = new Object();
        Object lock2 = new Object();
        Thread t1 = new Thread(() -> {
            synchronized (lock1) {
                System.out.println( "t1:已经获取到锁1");
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2) {
                    System.out.println( "t1:获取到锁2");
                }
            }
        }, "t1");
        t1.start();

        Thread t2 = new Thread(() -> {
            synchronized (lock2) {
                System.out.println( "t2:获取到锁2");
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock1) {
                    System.out.println(  "t2:获取到锁1");
                }
            }
        }, "t2");
        t2.start();
    }
}

死锁问题【javaEE初阶】_第1张图片 一直等待,死锁了

(三)多个线程多个锁,"哲学家就餐问题" 

此时,这种情况和 第二种情况 类似,只是更复杂一点而已 

在多个线程多把锁的情况下,"死锁"问题 就是一个概率性的问题,但是也绝对不能忽视 ! 

在谈到 "多个线程多把锁" 的时候,就会引出一个很经典的问题 —— "哲学家就餐问题" ! 

故事背景:

有 5 个哲学家,相当于有 5 个线程,他们只会做两件事情:

        思考人生(相当于是 线程休眠)
        吃面条(相当于是 在CPU上运行)
由于多线程的调度是无序的,所以说 这几个哲学家 什么时候去思考人生,什么时候去吃面条,我们是不确定的  

但是,此时 在餐桌上 一共只有 5 根筷子,并且 这5 根筷子 分别在 两两哲学家 之间 

并且,他们之间都不相互嫌弃,吃面条的时候要拿起 左右手两双筷子(这就导致相邻的哲学家需要等待) ~

此处的筷子就视为 两把"锁",只有这两把锁都获取到了,才可以吃面条 ~ 

出现 "死锁" 问题的情况:

假设 在同一时刻,所有的哲学家都想吃面条 ~

他们同时伸出左手,拿起左边的筷子;然后又同时伸出右手,尝试去拿右边的筷子;此时,右手的筷子都拿不起来,因此都无法吃面 

由于哲学家都非常固执,导致即使吃不到面条 也不会放下左手的筷子,这样的情况就会一直持续下去  ,这就构成了死锁  


 二、产生 "死锁" 的必要条件

鉴于 "死锁"问题,程序员大佬们 总结了 4 个 "死锁"产生的必要条件:

  1. 互斥使用(线程1 拿到锁A,其他线程就无法获取到 A)
  2. 不可抢占(线程1 拿到锁A,其他线程只能阻塞等待,等到线程1 主动释放锁,而不是强行把锁抢走)
  3. 请求和保持(当线程1 拿到锁A 之后,就会一直持有这个获取到锁的状态,直到说主动释放锁) 
  4. 循环等待(线程1 等待线程2,线程2 又尝试等待线程1)

三、解决 "死锁" 问题的办法

  1. 资源一次性分配:一次性分配所有资源,这样就不会再有请求了:(破坏请求条件)
  2. 只要有一个资源得不到分配,也不给这个进程分配其他的资源:(破坏请保持条件)
  3. 可剥夺资源:即当某进程获得了部分资源,但得不到其它资源,则释放已占有的资源(破坏不可剥夺条件)
  4. 资源有序分配法:系统给每类资源赋予一个编号,每一个进程按编号递增的顺序请求资源,释放则相反(破坏环路等待条件) 

根据 产生 "死锁" 的必要条件,我们可以知道,前三个必要条件 都是在描述锁的基本特点,在实际情况下 我们并不好直接去破坏 

但是,第四个必要条件 却是和代码编写密切相关  

如果我们能够在编码上做出一些注意和约定,就可以打破 "循环等待",避免死锁 !!!

1、以确定的顺序获得锁

         针对两个特定的锁,开发者可以尝试按照锁对象的hashCode值大小的顺序,分别获得两个锁,这样锁总是会以特定的顺序获得锁,那么死锁也不会发生。问题变得更加复杂一些,如果此时有多个线程,都在竞争不同的锁,简单按照锁对象的hashCode进行排序(单纯按照hashCode顺序排序会出现“环路等待”),可能就无法满足要求了,这个时候开发者可以使用银行家算法,所有的锁都按照特定的顺序获取,同样可以防止死锁的发生。

针对多把锁,进行编号:1、2、3、4、......

并且约定在获取多把锁的时候,要明确获取锁的顺序是 从小到大(或者 从大到小) 的顺序 

如(此处以从小到大为例):

线程要拿到 1、2 这两把锁,就先获取 1,再获取 2;

线程要拿到 2、4 这两把锁,就先获取 2,再获取 4 ~

只要所有的线程都遵循这个顺序,就不会出现 "循环等待",就不会出现死锁 !!!  

我们可以把这个解决办法 带入到上面的 "哲学家就餐问题" 看看 ~

约定:获取所得顺序是:从小到大 ~

 

 之后,最左边的哲学家 就可以得到两把锁了,于是就可以吃到面条了 ~

等到 吃完面条之后,会释放 4、5两把筷子;然后 最上面的哲学家 也可以吃到面条了,......,就这样的话,顺时针旋转,依次 5 位哲学家都可以吃上面条了 

2、超时放弃

        当使用synchronized关键词提供的内置锁时,只要线程没有获得锁,那么就会永远等待下去,然而Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法,该方法可以按照固定时长等待锁,因此线程可以在获取锁超时以后,主动释放之前已经获得的所有的锁。通过这种方式,也可以很有效地避免死锁。 

避免死锁:

  • 预防死锁的几种策略,会严重地损害系统性能。因此在避免死锁时,要施加较弱的限制,从而获得 较满意的系统性能。由于在避免死锁的策略中,允许进程动态地申请资源。因而,系统在进行资源分配之前预先计算资源分配的安全性。若此次分配不会导致系统进入不安全的状态,则将资源分配给进程;否则,进程等待。其中最具有代表性的避免死锁算法是银行家算法。
  • 银行家算法:首先需要定义状态和安全状态的概念。系统的状态是当前给进程分配的资源情况。因此,状态包含两个向量Resource(系统中每种资源的总量)和Available(未分配给进程的每种资源的总量)及两个矩阵Claim(表示进程对资源的需求)和Allocation(表示当前分配给进程的资源)。安全状态是指至少有一个资源分配序列不会导致死锁。当进程请求一组资源时,假设同意该请求,从而改变了系统的状态,然后确定其结果是否还处于安全状态。如果是,同意这个请求;如果不是,阻塞该进程知道同意该请求后系统状态仍然是安全的。

检测死锁

  1. 首先为每个进程和每个资源指定一个唯一的号码;
  2. 然后建立资源分配表和进程等待表。

解除死锁:

当发现有进程死锁后,便应立即把它从死锁状态中解脱出来,常采用的方法有:

  1. 剥夺资源:从其它进程剥夺足够数量的资源给死锁进程,以解除死锁状态;
  2. 撤消进程:可以直接撤消死锁进程或撤消代价最小的进程,直至有足够的资源可用,死锁状态.消除为止;所谓代价是指优先级、运行代价、进程的重要性和价值等。 

死锁检测

1、Jstack命令

        jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。 Jstack工具可以用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做什么事情,或者等待什么资源。

2、JConsole工具

        Jconsole是JDK自带的监控工具,在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM,对运行在Java应用程序的资源消耗和性能进行监控,并画出大量的图表,提供强大的可视化界面。而且本身占用的服务器内存很小,甚至可以说几乎不消耗。 

你可能感兴趣的:(初学java,java,开发语言)