死锁的产生、条件、和解锁

所谓死锁<DeadLock>: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程.

  由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了一种特殊现象死锁。
  一种情形,此时执行程序中两个或多个线程发生永久堵塞(等待),每个线程都在等待被其他线程占用并堵塞了的资源。例如,如果线程A锁住了记录1并等待记录2,而线程B锁住了记录2并等待记录1,这样两个线程就发生了死锁现象。
  计算机系统中,如果系统的资源分配策略不当,更常见的可能是程序员写的程序有错误等,则会导致进程因竞争资源不当而产生死锁的现象。

 产生死锁的原因主要是:

  (1) 因为系统资源不足。
  (2) 进程运行推进的顺序不合适。
  (3) 资源分配不当等。
  如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则
  就会因争夺有限的资源而陷入死锁。其次,进程运行推进顺序与速度不同,也可能产生死锁。

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

  (1) 互斥条件:一个资源每次只能被一个进程使用。
  (2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
  (3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
  (4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
  这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之
  一不满足,就不会发生死锁。

 死锁的解除与预防

  理解了死锁的原因,尤其是产生死锁的四个必要条件,就可以最大可能地避免、预防和解除死锁。所以,在系统设计、进程调度等方面注意如何不让这四个必要条件成立,如何确定资源的合理分配算法,避免进程永久占据系统资源。此外,也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中,对进程发出的每一个系统能够满足的资源申请进行动态检查,并根据检查结果决定是否分配资源,若分配后系统可能发生死锁,则不予分配,否则予以分配。因此,对资源的分配要给予合理的规划。
  一、有序资源分配法
  这种算法资源按某种规则系统中的所有资源统一编号(例如打印机为1、磁带机为2、磁盘为3、等等),申请时必须以上升的次序。系统要求申请进程:
  1、对它所必须使用的而且属于同一类的所有资源,必须一次申请完;
  2、在申请不同类资源时,必须按各类设备的编号依次申请。例如:进程PA,使用资源的顺序是R1,R2;进程PB,使用资源的顺序是R2,R1;若采用动态分配有可能形成环路条件,造成死锁。
  采用有序资源分配法:R1的编号为1,R2的编号为2;
  PA:申请次序应是:R1,R2
  PB:申请次序应是:R1,R2
  这样就破坏了环路条件,避免了死锁的发生
  二、银行算法
  避免死锁算法中最有代表性的算法是Dijkstra E.W 于1968年提出的银行家算法:
  该算法需要检查申请者对资源的最大需求量,如果系统现存的各类资源可以满足申请者的请求,就满足申请者的请求。
  这样申请者就可很快完成其计算,然后释放它占用的资源,从而保证了系统中的所有进程都能完成,所以可避免死锁的发生。

 死锁排除的方法

  1、撤消陷于死锁的全部进程;
  2、逐个撤消陷于死锁的进程,直到死锁不存在;
  3、从陷于死锁的进程中逐个强迫放弃所占用的资源,直至死锁消失。
  4、从另外一些进程那里强行剥夺足够数量的资源分配给死锁进程,以解除死锁状态
### 死锁产生必要条件 死锁的发生依赖于四个必要的条件,这些条件共同作用导致进程陷入无法继续执行的状态: - **互斥条件**:至少有一个资源必须处于不可抢占状态;即当一个资源被某个进程占用时,其他试图访问该资源的进程必须等待直到当前持有者释放它[^4]。 - **请求与保持条件**:已经获得某些资源的一个或多个进程可以进一步申请新的资源而未得到满足之前不会主动放弃已有的资源。 - **不可剥夺条件**:指一旦有进程获得了某项资源,在其未使用完毕前不允许强行收回此资源,只有占有它的那个进程能够显式地释放该项资源。 - **循环等待条件**:存在一系列等待着获取由链中下一个成员所持有的资源的过程形成闭合回路的情况发生。 ### 典型的死锁场景及其解决方案 #### 场景一:两个线程互相等待对方持有的锁 考虑如下情况下的Java程序片段,其中`process_a``process_b`分别尝试获取不同的对象上的同步锁,并且在成功取得第一个锁之后再去争取第二个不同步的对象上加锁。如果这两个过程恰好交错,则可能导致双方都在等待另一个先解锁从而进入僵持不下——这就是所谓的“双向死锁”。 ```java public class DeadlockExample { private final Object lockA = new Object(); private final Object lockB = new Object(); public void processA() { synchronized (lockA) { try { Thread.sleep(100); synchronized (lockB) { System.out.println("Process A completed"); } } catch (InterruptedException e) {} } } public void processB() { synchronized (lockB) { try { Thread.sleep(100); synchronized (lockA) { System.out.println("Process B completed"); } } catch (InterruptedException e) {} } } } ``` 为了避免这种情况,可以通过调整加锁顺序来打破可能形成的循环等待路径或者采用更高级别的并发控制结构如读写锁等[^3]。 #### 场景二:数据库事务中的死锁 在一个关系型数据库管理系统(RDBMS)环境中,当多个客户端应用程序几乎同时发起涉及相同表记录的操作(比如更新),并且各自都希望独占性地锁定那些正在处理的数据行以便完成自己的工作单元时,就有可能遇到类似的竞争局面进而引发死锁现象。为了应对这类问题,通常会采取诸如设置较短的时间间隔重试失败操作或是利用乐观/悲观锁机制等方式来进行优化设计以减少冲突概率并提高系统的整体吞吐量[^5]。 #### 场景三:网络通信协议层面的死锁 在网络编程领域里也存在着潜在的风险因素可能会引起死锁状况。例如TCP连接建立过程中若一方发送SYN包后长时间收不到ACK确认响应则会被认为是超时错误;但如果此时另一端正好也在做同样的事情就会造成两者都无法正常建立起有效链接的现象。针对这种情形一般建议通过实现心跳探测功能定期检查远端节点存活状态以及合理配置参数阈值范围内的自动断开重建逻辑来规避风险[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值