操作系统笔记-2.4.4 死锁的处理策略—检测和解除

噜～噜～噜～

20人浏览 · 2026-09-06 15:24:16

噜～噜～噜～ · 2026-09-06 15:24:16 发布

王道操作系统笔记，视频链接：2.4.4 死锁的处理策略—检测和解除

知识总览

死锁的处理：
- 不允许死锁发生：
  - 静态策略：预防死锁
  - 动态策略：避免死锁
- 允许死锁发生：
  - 死锁的检测和解除（本节内容）
    - 死锁的检测
    - 死锁的解除
如果系统中既不采取预防死锁的措施，也不采取避免死锁的措施，系统就很可能发生死锁。在这种情况下，系统应当提供两个算法：
- ①死锁检测算法：用于检测系统状态，以确定系统中是否发生了死锁。
- ②死锁解除算法：当认定系统中已经发生了死锁，利用该算法可将系统从死锁状态中解脱出来。

死锁的检测

为了能对系统是否已发生了死锁进行检测，必须：
- ①用某种数据结构来保存资源的请求和分配信息；
- ②提供一种算法，利用上述信息来检测系统是否已进入死锁状态。
数据结构——资源分配图：
- 两种结点：
  - 进程结点：对应一个进程
  - 资源结点：对应一类资源，一类资源可能有多个
- 两种边：
  - 进程结点 $\to$ 资源结点：表示进程想申请几个资源（每条边代表一个）
  - 资源结点 $\to$ 进程结点：表示已经为进程分配了几个资源（每条边代表一个）
- PS：一般用矩形表示资源结点，矩形中的小圆代表该类资源的数量。
- 如图所示：
分析过程：
- 如果系统中剩余的可用资源数足够满足进程的需求，
- 那么这个进程暂时是不会阻塞的，可以顺利地执行下去。
- 如果这个进程执行结束了把资源归还系统，
- 就可能使某些正在等待资源的进程被激活，并顺利地执行下去。
- 相应的，这些被激活的进程执行完了之后又会归还一些资源，
- 这样可能又会激活另外一些阻塞的进程……
如果按上述过程分析，最终能消除所有边，就称这个图是可完全简化的。
- 此时一定没有发生死锁（相当于能找到一个安全序列）
- 比如第2点中的示例图，按照P1、P2的顺序执行，就是一个安全序列
- 如果最终不能消除所有边，那么此时就是发生了死锁
- 一个新的例子：
  - 由于R1和R2资源都被分配完毕，所以P1、P2都会被阻塞，只有P3运行
  - P3运行完毕后返还一个R2资源，由于P1申请两个，所以资源数量不够，
  - 于是P1、P2都无法继续运行，发生了死锁
  - 如图所示：
最终还连着边的那些进程就是处于死锁状态的进程，比如第4点中的例子，在P3返还资源后的图如下，此时P1、P2就是处于死锁状态的进程，P3不是：
检测死锁的算法：
- ①在资源分配图中，找出既不阻塞又不是孤点的进程 Pi ，
  - 即找出一条有向边与它相连，且该有向边对应资源的申请数量小于等于系统中已有空闲资源数量。
  - 如下图中，R1没有空闲资源，R2有一个空闲资源。
  - 若所有的连接该进程的边均满足上述条件，则这个进程能继续运行直至完成，
  - 然后释放它所占有的所有资源，消去它所有的请求边和分配边，使之称为孤立的结点。
  - 在下图中，P1是满足这一条件的进程结点，于是可以将P1的所有边消去。
- ②进程 Pi 所释放的资源，可以唤醒某些因等待这些资源而阻塞的进程，
  - 原来的阻塞进程可能变为非阻塞进程。
  - 在下图中，P2 就满足这样的条件。
  - 根据①中的方法进行一系列简化后，
  - 若能消去途中所有的边，则称该图是可完全简化的。
- 图：
死锁定理：如果某时刻系统的资源分配图是不可完全简化的，那么此时系统死锁。
- PS：可自行搜索该定理的证明过程

死锁的解除

一旦检测出死锁的发生，就应该立即解除死锁。
并不是系统中所有的进程都是死锁状态，
- 用死锁检测算法化简资源分配图后，还连着边的那些进程就是死锁进程
解除死锁的主要方法有：
- ①资源剥夺法：
  - 挂起（暂时放到外存上）某些死锁进程，并抢占它的资源，
  - 将这些资源分配给其他的死锁进程。
  - 但是应防止被挂起的进程长时间得不到资源而饥饿。
- ②撤销进程法（或称终止进程法）：
  - 强制撤销部分、甚至全部死锁进程，并剥夺这些进程的资源。
  - 这种方式的优点是实现简单，但所付出的代价可能会很大。
  - 因为有些进程可能已经运行了很长时间，已经接近结束了，
  - 一旦被终止可谓功亏一篑，以后还得从头再来。
- ③进程回退法：
  - 让一个或多个死锁进程回退到足以避免死锁的地步。
    - 比如之前死锁的检测中第五点的例子，
    - 让P1回退到只拥有一个R1的情况，此时就可以空出一个R1给P2用
  - 这就要求系统要记录进程的历史信息，设置还原点。
    - 所以也不太容易实现
如何决定“对谁动手”：
- 进程优先级
  - 优先级越低，撤销代价越小
- 已执行多长时间
  - 执行时间越长，代表撤销代价越大
- 还要多久能完成
  - 需要时间越短，返还资源速度越快
- 进程已经使用了多少资源
  - 使用资源越多，撤销后返还的资源越多
- 进程是交互式的还是批处理式的
  - 交互式实时性强，撤销会严重破坏用户体验
  - 批处理式实时性弱，撤销代价相对交互性小