操作系统_死锁
资源
死锁定义
多个进程各自占有不可抢占独占资源,同时互相等待对方持有的资源,双方都不释放已有资源、永久阻塞,这种循环等待状态就是死锁(deadlock);跨机器、数据库场景都会出现死锁。
资源分类(核心两类)
-
可抢占资源
系统可强制从进程手中收回,无严重故障,如内存;即使产生冲突也容易化解死锁。
-
不可抢占资源
进程占用后除非主动释放 / 异常,否则不能被抢夺,如打印机、光驱;死锁大多发生在这类资源,处理难度更高。
资源完整生命周期
请求资源 → 使用资源 → 释放资源

资源访问实现:信号量 / 互斥锁
-
互斥锁 Mutex:保证资源同一时间仅一个线程访问,使用前加锁、用完解锁。
-
二元信号量(初值 = 1)
:实现独占资源管控
down()(P 操作):申请资源,信号量为 0 则进程阻塞;成功则信号量 - 1;up()(V 操作):释放资源,信号量 + 1,唤醒等待该资源的阻塞进程。
死锁高发场景:不可抢占独占资源、多进程并发、资源获取顺序相反;
单进程无竞争,不存在死锁;
规避死锁最简单方案:统一所有进程获取资源的先后顺序,消除循环等待条件;
可抢占资源死锁易解决,不可抢占资源死锁只能靠外部干预(手动释放资源、重启进程)解除。
死锁
死锁定义
一组进程互相等待对方释放独占资源,所有进程永久阻塞、无法推进,该状态称为死锁(资源死锁是最常见类型)。
简单场景:进程 A 占 R1 等 R2,进程 B 占 R2 等 R1,互相僵持,无进程能释放资源。
资源死锁4条件
资源死锁四大必要条件(必须同时满足才会死锁,破坏任意一条即可避免)
互斥条件
资源同一时刻仅能被一个进程占用,资源具备独占性(例:打印机)。
占有且等待(保持和等待)
进程已持有部分资源,不释放已有资源,同时申请新资源。
不可抢占条件
资源只能由持有者主动释放,系统不能强制抢夺资源。
循环等待条件
存在环形等待链:P1 等 P2 资源、P2 等 P3 资源…… 最后一个进程等待 P1 的资源,形成闭环
死锁模型

圆形:进程;方形:资源
资源→进程箭头:该资源已分配给这个进程
进程→资源箭头:进程阻塞,正在请求该资源
资源分配图中存在完整环路,则系统发生死锁;无环路则无死锁。
处理死锁的策略
策略 1:忽略死锁(鸵鸟算法)
适用场景:小型 / 嵌入式系统,死锁概率极低、后果轻微;
缺点:大型、关键业务系统不可用,死锁会引发严重故障。
策略 2:死锁检测 + 恢复(事后处理)
-
运行时持续跟踪资源分配、进程等待关系,检测死锁环路;
-
死锁出现后恢复手段:抢占资源、回滚进程事务、重启系统 / 进程;
策略 3:静态预防 —— 破坏四大必要条件之一(事前杜绝死锁)
策略 4:动态避免(运行时预判,代表:银行家算法)
进程申请资源时,系统预判分配后系统是否处于安全状态(存在完整执行序列,所有进程能顺利完成);
若分配后不安全,则拒绝本次资源申请,从源头阻止死锁产生。
鸵鸟算法
鸵鸟算法是处理死锁最简单、但风险最高的策略,核心思想是逃避问题:假设死锁发生概率极低,系统不做任何检测、预防、恢复操作,假装死锁不存在,放任系统自行运行。名称来源于鸵鸟遇危险埋头沙中、无视风险的行为。
死锁检测和恢复
死锁检测与恢复属于事后处理方案,和死锁预防 / 避免不同:它不阻止死锁发生,允许死锁出现,系统定时 / 实时检测到死锁后,执行恢复操作解除死锁。
检测基础:资源分配表模型

系统维护 4 类核心数据向量 / 矩阵:
- 现有资源向量 E:系统每种资源总数量
- 可用资源向量 A:当前空闲未分配的资源
- 分配矩阵 C:
******]代表进程 Pn 当前占用 m 类资源的数量 - 请求矩阵 R:
R[n][m]代表进程 Pn 还需要申请的 m 类资源数量
即时检测
- 触发条件:每次进程发起资源请求时立刻执行检测
- 优点:死锁发现及时,快速处理
- 缺点:频繁触发会大量消耗 CPU,高并发场景严重降低系统性能
定期检测
- 触发条件:固定时间间隔 / CPU 利用率低于阈值(空闲资源多)时执行
- 优点:平衡性能与检测及时性,低负载时检测几乎不影响业务
检测算法原理
- 初始所有进程标记为未标记;
- 遍历进程:若当前可用资源能满足该进程全部请求,则标记该进程,释放它持有的资源到可用资源;
- 循环执行,直到无新进程可标记;
- 最终未被标记的进程,全部处于死锁状态。
抢占资源恢复 操作逻辑:系统强制剥夺死锁进程持有的资源,分配给等待资源的进程;任务完成后归还资源
进程回滚恢复 前置准备:提前设置检查点,定期保存进程快照(内存、变量、资源占用状态),独立存储多个时间点快照;
恢复流程:检测死锁后,将死锁进程回滚至最近检查点;此时进程未持有形成死锁的资源,系统重新分配资源打破循环等待;
死锁避免
银行家算法

破坏死锁
也就是破坏4个条件里面任意一个就行
| 破坏条件 | 实现方法 | 优点 | 主要缺陷 |
|---|---|---|---|
| 互斥 | 假脱机缓冲 | 适配打印类独占设备 | 硬件资源无法共享,缓冲区次生死锁 |
| 保持等待 | 一次性申请全部资源 | 理论无死锁 | 资源利用率极低,需求预判困难 |
| 不可抢占 | 虚拟化动态抢占 | 资源可回收复用 | 易破坏数据完整性,事务场景禁用 |
| 循环等待 | 资源全局编号顺序申请 | 实现简单、性能损耗小 | 低频资源强制申请,浪费系统资源 |
其他
加锁阶段(增长阶段):事务一次性申请所有需要的记录锁;若任意记录被占用,释放当前已获取全部锁,重新重试。
释放阶段(收缩阶段):所有锁全部获取成功后,执行业务更新,完成后统一释放所有锁;释放锁后不再申请任何新锁。
| 类型 | 进程状态 | 核心特征 | 产生根源 |
|---|---|---|---|
| 死锁 | 阻塞休眠 | 多进程循环等待对方资源,完全停滞 | 同时满足死锁四大必要条件 |
| 活锁 | 持续运行、占用 CPU | 进程反复释放、重试获取锁,无推进 | 无随机等待,同步礼让重试 |
| 饥饿 | 就绪等待 | 单个进程长期抢不到资源,持续被插队 | 不公平的资源调度策略 |
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
所有评论(0)