关于死锁

死锁是指两个或多个进程在争夺资源时形成的僵局,无法自行解脱。本文详细介绍了死锁的定义、原因、四要素以及处理死锁的各种方法,包括预防和避免策略,如破坏四个必要条件、银行家算法、加锁顺序、超时机制和死锁检测等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

什么是死锁

死锁是指两个或两个以上的进程在运行过程中因争夺资源而造成的一种僵局,若无外力作用,这些进程都将无法向前推进。

死锁的原因

  • 竞争不可抢占资源引起死锁
    通常系统中拥有的不可抢占资源,其数量不足以满足多个进程运行的需要,使得进程在运行过程中,会因争夺资源而陷入僵局,如磁带机、打印机等。只有对不可抢占资源的竞争才能产生死锁。
  • 竞争可消耗资源引起死锁
  • 进程推进顺序不当引起死锁
    进程在运行过程中,请求和释放资源的顺序不当,也同样会导致死锁。例如,并发进程 P1、P2分别保持了资源R1、R2,而进程P1申请资源R2,进程P2申请资源R1时,两者都会因为所需资源被占用而阻塞。
    信号量使用不当也会造成死锁。进程间彼此相互等待对方发来的消息,结果也会使得这 些进程间无法继续向前推进。例如,进程A等待进程B发的消息,进程B又在等待进程A 发的消息,可以看出进程A和B不是因为竞争同一资源,而是在等待对方的资源导致死锁。

死锁四要素(必要条件)

互斥

进程要求对所分配的资源进行排他性控制,即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源,则请求进程只能等待,如果A进程持有a资源,请求b资源,B进程持有b资源,请求a资源,相互等待就会造成死锁。

不可剥夺

进程所获得的资源在未使用完毕之前,不能被其他进程强行夺走,即只能由获得该资源的进程来释放(持有资源的进程主动释放)。

请求与保持

进程已经保持了至少一个资源(A),但又提出了新的资源(B)请求,而该资源(B)已被其他进程占有,该进程会被阻塞而无法释放资源(A)。

循环等待

当两个进程相互等待时我们很容易就能观察来,但是如果多个进程相互等待形成闭环就很难观察出来。循环等待打破方式:
在这里插入图片描述
图2-16中向我们展现了另一种循环等待,Pn在等待P0和PK资源的释放,而PK是不属于闭环的,只要PK释放了资源,就能打破循环等待的局面。

两个线程互相等待资源的例子

public class 等待死锁 implements Runnable {
  public int flag= 1;
  //静态对象是类的所有对象共享的
  private static Object o1=new Object();
  private static Object o2=new Object();
  
	@Override
	public void run() {
		// TODO Auto-generated method stub
		System.out.println("flag="+flag);
		if (flag==1) {
			//给对象o1上同步锁独享
			synchronized (o1) {
				try {
					Thread.sleep(500);
				} catch (Exception e) {
					// TODO: handle exception
					e.printStackTrace();
				}
			}
			//给对象o2上同步锁独享
			synchronized (o2) {
				System.out.println("1");
			}
		}
		if (flag==0) {
			synchronized (o2) {
			try {
				Thread.sleep(500);
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}	
			}
			synchronized (o1) {
			System.out.println("0");	
			}
		}
	}
	public static void main(String[] args) {
		等待死锁 T1=new 等待死锁();
		等待死锁 T2=new 等待死锁();
		T1.flag=1;
		T1.flag=0;
		new Thread(T1).start();
		new Thread(T2).start();
	}
	
}

处理死锁的方法

预防死锁

通过设置某些限制条件,去破坏产生死锁的四个必要条件中的一个或几个条件,来防止死锁的产生。

破坏“互斥”条件

**若资源不被一个进程独占使用,那么死锁是肯定不会发生的。**但一般来说在所列的四个条件中,“互斥”条件是无法破坏的。因此,在死锁预防里主要是破坏其他几个必要的条件,而不去设计破坏“互斥”条件。(因为对于另一个线程突然抢占本线程持有的资源带来的风险极大)。

互斥条件不能被破坏,否则会造成结果的不可再现性。(突然抢占很难模拟)

破坏“占有并等待”条件

破坏“占有并等待”条件,就是在系统中不允许进程在已获得某种资源的情况下,申请其他资源。即要想出一个办法,阻止进程在持有资源的同时申请其他资源。
方法一:创建进程时,要求它申请所需的全部资源,系统或满足其所有要求,或什么也不给它。这是所谓的 “ 一次性分配”方案。
方法二:要求每个进程提出新的资源申请前,释放它所占有的资源。这样,一个进程在需要资源S时,须先把它先前占有的资源R释放掉,然后才能提出对S的申请,即使它可能很快又要用到资源R。

破坏“不可抢占”条件

破坏“不可抢占”条件就是允许对资源实行抢夺。
方法一:如果占有某些资源的一个进程进行进一步资源请求被拒绝,则该进程必须释放它最初占有的资源,如果有必要,可再次请求这些资源和另外的资源。
方法二:如果一个进程请求当前被另一个进程占有的一个资源,则操作系统可以抢占另一个进程,要求它释放资源。只有在任意两个进程的优先级都不相同的条件下,方法二才能预防死锁。

破坏“循环等待”条件

破坏“循环等待”条件的一种方法,是将系统中的所有资源统一编号,进程可在任何时刻提出资源申请,但所有申请必须按照资源的编号顺序(升序)提出。这样做就能保证系统不出现死锁。

避免死锁

在资源的动态分配过程中,用某种方法去防止系统进入不安全状态,从而避免死锁的发生。
预防死锁和避免死锁的区别:
预防死锁是设法至少破坏产生死锁的四个必要条件之一,严格的防止死锁的出现,而避免死锁则不那么严格的限制产生死锁的必要条件的存在,因为即使死锁的必要条件存在,也不一定发生死锁。避免死锁是在系统运行过程中注意避免死锁的最终发生。

有序资源分配法

这种算法资源按某种规则系统中的所有资源统一编号(例如打印机为1、磁带机为2、磁盘为3、等等),申请时必须以上升的次序。系统要求申请进程:
  1、对它所必须使用的而且属于同一类的所有资源,必须一次申请完;
  2、在申请不同类资源时,必须按各类设备的编号依次申请。例如:进程PA,使用资源的顺序是R1,R2; 进程PB,使用资源的顺序是R2,R1;若采用动态分配有可能形成环路条件,造成死锁。
  采用有序资源分配法:R1的编号为1,R2的编号为2;
  PA:申请次序应是:R1,R2
  PB:申请次序应是:R1,R2
  这样就破坏了环路条件,避免了死锁的发生。

银行家算法

根据可用资源与所需资源调整线程对资源的占用顺序的算法。
银行家算法

加锁顺序

线程按照一定的顺序加锁。
当多个线程需要相同的一些锁,但是按照不同的顺序加锁,死锁就很容易发生。
如果能确保所有线程都是按照相同的顺序获得锁,那么死锁就不会发生。

Thread 1:
lock A
lock B
Thread 2:
wait for A
lock C (when A locked)
Thread 3:
wait for A
wait for B
wait for C

如果一个线程(比如线程3)需要一些锁,那么它必须按照确定的顺序获取锁。它只有获得了从顺序上排在前面的锁之后,才能获取后面的锁。

例如,线程2和线程3只有在获取了锁A之后才能尝试获取锁C(译者注:获取锁A是获取锁C的必要条件)。因为线程1已经拥有了锁A,所以线程2和3需要一直等到锁A被释放。然后在它们尝试对B或C加锁之前,必须成功地对A加了锁。

加锁时限

线程尝试获取锁的时候加上一定的时限,超过时限则放弃对该锁的请求,并释放自己占有的锁。
在尝试获取锁的时候加一个超时时间,这也就意味着在尝试获取锁的过程中若超过了这个时限该线程则放弃对该锁请求。若一个线程没有在给定的时限内成功获得所有需要的锁,则会进行回退并释放所有已经获得的锁,然后等待一段随机的时间再重试。这段随机的等待时间让其它线程有机会尝试获取相同的这些锁,并且让该应用在没有获得锁的时候可以继续运行

Thread 1 locks A
Thread 2 locks B
Thread 1 attempts to lock B but is blocked
Thread 2 attempts to lock A but is blocked
Thread 1’s lock attempt on B times out
Thread 1 backs up and releases A as well
Thread 1 waits randomly (e.g. 257 millis) before retrying.
Thread 2’s lock attempt on A times out
Thread 2 backs up and releases B as well
Thread 2 waits randomly (e.g. 43 millis) before retrying.

在上面的例子中,线程2比线程1早200毫秒进行重试加锁,因此它可以先成功地获取到两个锁。这时,线程1尝试获取锁A并且处于等待状态。当线程2结束时,线程1也可以顺利的获得这两个锁(除非线程2或者其它线程在线程1成功获得两个锁之前又获得其中的一些锁)。

需要注意的是,由于存在锁的超时,所以我们不能认为这种场景就一定是出现了死锁。也可能是因为获得了锁的线程(导致其它线程超时)需要很长的时间去完成它的任务。

此外,如果有非常多的线程同一时间去竞争同一批资源,就算有超时和回退机制,还是可能会导致这些线程重复地尝试但却始终得不到锁。如果只有两个线程,并且重试的超时时间设定为0到500毫秒之间,这种现象可能不会发生,但是如果是10个或20个线程情况就不同了。因为这些线程等待相等的重试时间的概率就高的多(或者非常接近以至于会出现问题)。

超时和重试机制是为了避免在同一时间出现的竞争,但是当线程很多时,其中两个或多个线程的超时时间一样或者接近的可能性就会很大,因此就算出现竞争而导致超时后,由于超时时间一样,它们又会同时开始重试,导致新一轮的竞争,带来了新的问题。

这种机制存在一个问题,在Java中不能对synchronized同步块设置超时时间。你需要创建一个自定义锁,或使用Java5中java.util.concurrent包下的工具

死锁检测

死锁检测是一个更好的死锁预防机制,它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。

每当一个线程获得了锁,会在线程和锁相关的数据结构中(map、graph等等)将其记下。除此之外,每当有线程请求锁,也需要记录在这个数据结构中。

当一个线程请求锁失败时,这个线程可以遍历锁的关系图看看是否有死锁发生。例如,线程A请求锁7,但是锁7这个时候被线程B持有,这时线程A就可以检查一下线程B是否已经请求了线程A当前所持有的锁。如果线程B确实有这样的请求,那么就是发生了死锁(线程A拥有锁1,请求锁7;线程B拥有锁7,请求锁1)。

当然,死锁一般要比两个线程互相持有对方的锁这种情况要复杂的多。线程A等待线程B,线程B等待线程C,线程C等待线程D,线程D又在等待线程A。线程A为了检测死锁,它需要递进地检测所有被B请求的锁。从线程B所请求的锁开始,线程A找到了线程C,然后又找到了线程D,发现线程D请求的锁被线程A自己持有着。这是它就知道发生了死锁。

下面是一幅关于四个线程(A,B,C和D)之间锁占有和请求的关系图。像这样的数据结构就可以被用来检测死锁。
在这里插入图片描述

检测死锁

允许系统在运行过程中发生死锁,但可设置检测机构及时检测死锁的发生,并采取适当措施加以清除。
一般来说,由于操作系统有并发,共享以及随机性等特点,通过预防和避免的手段达到排除死锁的目的是很困难的。这需要较大的系统开销,而且不能充分利用资源。为此,一种简便的方法是系统为进程分配资源时,不采取任何限制性措施,但是提供了检测和解脱死锁的手段:
能发现死锁并从死锁状态中恢复出来。因此,在实际的操作系统中往往采用死锁的检测与恢复方法来排除死锁。
死锁检测与恢复是指系统设有专门的机构,当死锁发生时,该机构能够检测到死锁发生的位置和原因,并能通过外力破坏死锁发生的必要条件,从而使得并发进程从死锁状态中恢复出来。

这时进程P1占有资源R1而申请资源R2,进程P2占有资源R2而申请资源R1,按循环等待条件,进程和资源形成了环路,所以系统是死锁状态。进程P1,P2是参与死锁的进程。

下面我们再来看一看死锁检测算法。算法使用的数据结构是如下这些:
占有矩阵A:nm阶,其中n表示并发进程的个数,m表示系统的各类资源的个数,这个矩阵记录了每一个进程当前占有各个资源类中资源的个数。
申请矩阵R:n
m阶,其中n表示并发进程的个数,m表示系统的各类资源的个数,这个矩阵记录了每一个进程当前要完成工作需要申请的各个资源类中资源的个数。
空闲向量T:记录当前m个资源类中空闲资源的个数。
完成向量F:布尔型向量值为真(true)或假(false),记录当前n个并发进程能否进行完。为真即能进行完,为假则不能进行完。
临时向量W:开始时W:=T。
算法步骤:
(1)W:=T,
对于所有的i=1,2,…,n,
如果A[i]=0,则F[i]:=true;否则,F[i]:=false
(2)找满足下面条件的下标i:
F[i]:=false并且R[i]〈=W
如果不存在满足上面的条件i,则转到步骤(4)。
(3)W:=W+A[i]
F[i]:=true
转到步骤(2)
(4)如果存在i,F[i]:=false,则系统处于死锁状态,且Pi进程参与了死锁。

什么时候进行死锁的检测取决于死锁发生的频率。如果死锁发生的频率高,那么死锁检测的频率也要相应提高,这样一方面可以提高系统资源的利用率,一方面可以避免更多的进程卷入死锁。如果进程申请资源不能满足就立刻进行检测,那么每当死锁形成时即能被发现,这和死锁避免的算法相近,只是系统的开销较大。为了减小死锁检测带来的系统开销,一般采取每隔一段时间进行一次死锁检测,或者在CPU的利用率降低到某一数值时,进行死锁的检测。

解锁死锁

当检测出死锁后,便采取适当措施将进程从死锁状态中解脱出来。
一旦检测出死锁,就应立即釆取相应的措施,以解除死锁。
死锁解除的主要方法有:

  1. 资源剥夺法。挂起某些死锁进程,并抢占它的资源,将这些资源分配给其他的死锁进程。但应防止被挂起的进程长时间得不到资源,而处于资源匮乏的状态。
  2. 撤销进程法。强制撤销部分、甚至全部死锁进程并剥夺这些进程的资源。撤销的原则可以按进程优先级和撤销进程代价的高低进行。
  3. 进程回退法。让一(多)个进程回退到足以回避死锁的地步,进程回退时自愿释放资源而不是被剥夺。要求系统保持进程的历史信息,设置还原点。
<think>好的,用户现在想了解死锁的定义、产生原因及解决方法。我之前已经回答过TCP/IP协议的问题,现在需要根据用户提供的引用材料来组织回答。首先,我需要确认用户提供的四个引用内容,确保正确引用到回答中。 用户给出的引用[1]提到死锁的定义、产生条件解决办法,特别是检测方法是通过检查进程资源的有向图是否存在环路。引用[2]讨论了可重入普通两次是否导致死锁的情况。引用[3][4]则涉及死锁的原因,如资源竞争,以及解决方法如回退随机等待。 接下来,我需要按照用户之前的回答结构来组织内容,确保使用正确的中文格式,如行内数学公式用$...$,独立公式用$$...$$,但可能这个回答中数学公式不多。然后需要生成相关问题,确保引用标识正确添加。 首先定义死锁,根据引用[1],死锁是多个进程互相等待对方释放资源,导致无法推进的状态。产生条件包括互斥、持有等待、不可剥夺循环等待。解决办法有预防、避免、检测解除。需要引用[1][4]来支持资源竞争的原因。 在产生原因部分,引用[4]提到系统资源竞争,特别是不可剥夺资源。引用[2]中的重入问题也是原因之一。解决方法中,引用[3]提到的回退随机等待需要包含,同时要提到死锁检测,如引用[1]中的环路检测。 最后生成相关问题,需要覆盖定义、条件、应用场景、检测方法、可重入等,参考用户之前的示例问题结构。确保每个引用在回答中有对应的标注,比如[^1]、[^2]等,且引用位置自然。</think>#### 死锁的定义与核心原理 **死锁**指多个进程(或线程)因竞争资源陷入互相等待的状态,导致所有进程无法继续执行。这种现象类似于交通堵塞中的“环形等待”,每个进程都持有对方所需的资源且不释放[^1][^4]。 --- #### 一、死锁产生的四大必要条件 1. **互斥条件** 资源具有独占性(如打印机、数据库连接),同一时间只能被一个进程使用[^4]。 2. **持有等待** 进程已持有至少一个资源,同时请求其他进程占有的资源且不释放已有资源[^1][^4]。 3. **不可剥夺** 资源只能由持有者主动释放,无法被系统强制回收(如未保存的文件句柄)[^4]。 4. **循环等待** 存在进程集合 $\{P_1, P_2, ..., P_n\}$,其中每个 $P_i$ 都在等待 $P_{i+1}$ 持有的资源,且 $P_n$ 等待 $P_1$ 的资源,形成环形依赖[^1][^3]。 --- #### 二、死锁产生的直接原因 1. **资源竞争** 当多个进程争夺不可剥夺资源(如硬件设备)且资源数量不足时,可能引发僵局[^4]。 2. **编程设计缺陷** - **不可重入**:若线程对同一连续加两次且不可重入,会导致自身阻塞(如引用[^2]中描述的线程自阻塞)。 - **顺序不一致**:线程以不同顺序获取多把,可能形成循环等待[^3]。 3. **系统调度策略** 操作系统未合理分配资源或未检测资源分配图,可能放大死锁风险[^1]。 --- #### 三、死锁解决方案 | **方法** | **实现原理** | **典型场景** | |-----------------|----------------------------------------------------------------------------|----------------------------------| | **预防策略** | 破坏任一必要条件:<br> - 资源一次性分配(破坏持有等待)<br> - 允许资源剥夺(破坏不可剥夺性) | 嵌入式系统、实时控制系统 | | **避免策略** | 通过银行家算法预判资源分配是否安全 | 资源类型固定的场景(如内存管理) | | **检测与恢复** | 周期性地构建资源分配图,检测环路:<br> $$G=(V,E) \text{ 中存在环} \Rightarrow \text{死锁}$$<br> 发现后强制终止进程或回滚操作[^1][^3] | 数据库事务管理、分布式系统 | | **忽略策略** | 假设死锁概率极低(如UNIX系统默认处理方式) | 通用操作系统 | --- #### 四、开发中的实践建议 1. **顺序标准化** 多线程编程中固定的获取顺序(如按内存地址升序),避免循环等待。 2. **使用可重入** 通过支持重入的(如Java的`ReentrantLock`)防止线程自阻塞[^2]。 3. **超时回退机制** 若获取超时,释放已持有随机等待后重试(如引用中的回退策略)。 --- #### 五、典型问题解析 **问题**:线程对同一不可重入连续加两次会死锁吗? **答案**: - **可重入**:允许线程重复加,计数器记录次数,不会死锁。 - **不可重入**:第二次加时线程自身被阻塞,导致死锁[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值