Linux之死锁

Mr_-G

于 2025-04-27 16:12:13 发布

阅读量471

点赞数 25

分类专栏：嵌入式软件开发 Linux 文章标签：大数据数据库嵌入式 linux 死锁软件开发

本文链接：https://blog.csdn.net/pythonsys/article/details/147562781

版权

Linux 同时被 2 个专栏收录

131 篇文章

订阅专栏

嵌入式软件开发

110 篇文章

订阅专栏

一、形象比喻：死锁就像两个孩子抢玩具

想象一个幼儿园的场景：
小明和小红各自手里拿着一半拼图玩具，但这两块拼图必须合在一起才能玩。

小明的需求：想玩完整的拼图，于是伸手去抢小红手里的另一半。
小红的需求：同样想玩完整的拼图，也紧紧攥住自己的一半不松手。

僵持局面出现了：

小明手里拿着拼图 A，却死死盯着小红的拼图 B，不肯松开自己的 A，也不放弃抢 B；
小红手里拿着拼图 B，同样盯着小明的拼图 A，既不松开 B，也不放弃抢 A。
结果：两人都卡在原地，谁也玩不成拼图，甚至急得哭闹起来。

这就是死锁的本质：
两个或多个进程（好比小明和小红）在争夺资源（拼图）时，互相持有对方需要的资源，又互相等待对方释放资源，导致所有进程都无法继续执行，像被 “锁死” 了一样。

二、死锁深度解析

一、死锁的定义与核心原理

死锁（Deadlock）是操作系统中进程管理的经典问题，指多个进程在执行过程中，因争夺互斥资源或调度顺序不当，导致所有进程都被永久阻塞，无法继续推进的状态。

1.1 死锁的四个必要条件（缺一不可）

条件	通俗解释	类比场景
互斥条件	资源一次只能被一个进程占用（如打印机、数据库锁）	教室唯一的投影仪被某小组使用
请求与保持	进程持有资源时，又请求其他资源且不释放已持有资源	左手拿筷子，右手还想拿勺子
不可剥夺	资源只能被进程主动释放，不能强制剥夺（如进程持有的内存空间）	别人手里的书不能直接抢走
循环等待	多个进程形成环形等待链，每个进程等待下一个进程持有的资源	A 等 B 的笔，B 等 C 的纸，C 等 A 的橡皮

关键点：只有四个条件同时满足时，死锁才会发生。操作系统的死锁处理策略，本质上是破坏其中至少一个条件。

二、死锁的常见类型与典型场景

2.1 按资源类型分类

抢占式资源死锁
- 资源可被强制剥夺（如 CPU 时间片），死锁较少见，但调度策略不当仍可能发生。
- 案例：实时系统中，高优先级进程等待低优先级进程持有的临时资源，而低优先级进程被高优先级进程抢占 CPU，无法释放资源。
非抢占式资源死锁
- 资源不可强制剥夺（如打印机、文件句柄），是死锁的主要发生场景。
- 案例：进程 A 占用打印机打印文件，同时请求扫描仪；进程 B 占用扫描仪扫描文件，同时请求打印机，形成循环等待。

2.2 按进程类型分类

进程间死锁
- 多个用户进程因资源竞争导致死锁（最常见）。
- 经典案例：哲学家就餐问题
  五位哲学家围坐餐桌，每人需同时拿到左右两支筷子才能吃饭。若所有哲学家同时拿起左手筷子，再等待右手筷子，就会陷入死锁（每人持有一支筷子，等待另一支）。
线程间死锁
- 同一进程内的多个线程因竞争锁资源（如互斥锁、递归锁）导致死锁。
- 案例：线程 1 锁定资源 A 后，尝试锁定资源 B；线程 2 锁定资源 B 后，尝试锁定资源 A，双方互相等待对方释放锁。

三、死锁的影响与检测方法

3.1 死锁的危害

资源浪费：死锁进程占用的资源（内存、文件句柄、硬件设备）被长期阻塞，无法被其他进程使用。
系统性能下降：操作系统需消耗额外资源检测死锁，严重时可能导致系统响应变慢甚至崩溃。
业务中断：在服务器场景中（如数据库事务锁），死锁可能导致交易失败、服务不可用。

3.2 死锁检测工具（以 Linux 为例）

ps + pstack
- ps -ef | grep <进程名> 定位死锁进程 PID
- pstack <PID> 查看进程内线程栈，分析线程是否卡在锁等待状态
```
# 示例：检测Nginx进程死锁  
ps -ef | grep nginx  
pstack 12345  # 假设PID为12345  
```
lsof（List Open Files）
- 查看进程打开的文件描述符、网络连接等资源，判断是否持有冲突资源。
```
lsof -p <PID> | grep 'deleted'  # 检测已删除但未释放的文件句柄  
```
strace/ltrace
- strace 跟踪系统调用，ltrace 跟踪库函数调用，定位进程阻塞点。
```
strace -p <PID>  # 查看进程是否卡在read/write等系统调用  
```
内核工具：deadlock detector
- 部分 Linux 内核版本内置死锁检测模块（如lockdep），可通过内核日志（dmesg）查看死锁警告。

四、死锁的处理策略

操作系统处理死锁有三种核心策略：预防、避免、检测与解除，对应不同的复杂度和资源利用率。

4.1 死锁预防：破坏必要条件

通过设计规则，提前破坏死锁的四个必要条件之一，确保死锁永不发生。

破坏互斥条件
- 允许资源共享（如使用 SPOOLing 技术将打印机虚拟为共享资源），但仅适用于非临界资源。
- 局限性：临界资源（如数据库写锁）必须互斥，此方法适用范围有限。
破坏请求与保持条件
- 要求进程一次性申请所有需要的资源，否则不分配任何资源。
- 案例：数据库事务开始前，先锁定所有需要的表 / 行。
- 缺点：资源利用率低（进程可能长期持有未使用的资源）。
破坏不可剥夺条件
- 允许操作系统强制剥夺进程持有的资源（如高优先级进程抢占低优先级进程的 CPU）。
- 适用场景：适用于 CPU、内存等可抢占资源，但对打印机等不可抢占资源无效。
破坏循环等待条件
- 对资源进行线性排序，要求进程按顺序申请资源，避免环形等待。
- 实现方法：
  - 为每个资源分配唯一编号（如打印机 = 1，扫描仪 = 2，磁盘 = 3）；
  - 进程必须按编号递增顺序申请资源（先申请 1，再申请 2，不能反向）。
- 案例：哲学家就餐问题中，规定奇数号哲学家先拿左筷子，偶数号先拿右筷子，避免所有人同时拿同一侧筷子。

4.2 死锁避免：动态资源分配策略

在资源分配过程中，通过算法预判分配是否会导致死锁，仅在安全状态下分配资源。

核心算法：银行家算法（Bankers Algorithm）

思想：模拟银行借贷系统，确保系统始终处于 “安全状态”（存在至少一个进程执行序列，使所有进程都能获得所需资源完成任务）。
数据结构：
- Available：系统可用资源向量
- Max：各进程所需资源最大值
- Allocation：各进程已分配资源量
- Need = Max - Allocation：各进程还需资源量
步骤：
1. 当进程请求资源时，先假设分配，计算新的资源状态；
2. 使用安全性算法检查新状态是否安全（是否存在安全序列）；
3. 若安全，实际分配资源；否则拒绝请求。

案例：银行家算法演示
假设系统有 3 类资源（A, B, C），4 个进程（P0-P3），当前状态如下：

进程	Allocation	Max	Need	Available
P0	(0,1,0)	(7,5,3)	(7,4,3)	(3,3,2)
P1	(2,0,0)	(3,2,2)	(1,2,2)
P2	(3,0,2)	(9,0,2)	(6,0,0)
P3	(2,1,1)	(2,2,2)	(0,1,1)

安全检查：
- 进程 P3 的Need=(0,1,1) ≤ Available=(3,3,2)，假设分配后Available=(1,2,1)，P3 完成后释放资源，Available=(3,3,2)；
- 进程 P1 的Need=(1,2,2) ≤ Available=(3,3,2)，分配后Available=(1,1,0)，P1 完成后释放资源，Available=(3,1,2)；
- 进程 P0 的Need=(7,4,3) ≤ Available=(3,1,2)？不满足，需继续检查 P2；
- 进程 P2 的Need=(6,0,0) ≤ Available=(3,1,2)？不满足。
- 结论：当前状态安全，因为存在安全序列[P3, P1, P0, P2]（假设后续资源可满足）。

4.3 死锁检测与解除：事后处理

当系统发生死锁后，通过检测算法发现死锁，并强制解除。

死锁检测算法
- 原理：构建进程 - 资源分配图（Resource Allocation Graph），检测图中是否存在环路。
- 步骤：
  1. 找出图中没有请求边的进程（即已获得所有所需资源的进程），标记为 “可运行”，并释放其持有的资源；
  2. 重复步骤 1，直到无法再标记新进程或图中仍有环路；
  3. 若存在未标记的进程，则说明发生死锁，这些进程即为死锁进程。
死锁解除方法
- 资源剥夺法：强制剥夺死锁进程持有的资源，分配给其他进程（需考虑进程恢复问题）。
- 撤销进程法：按优先级撤销部分死锁进程，释放其资源（如先撤销低优先级进程）。
- 进程回退法：让进程回退到之前的某个检查点（Checkpoint），重新申请资源（需操作系统支持进程回滚）。

五、Linux 系统中的死锁优化实践

5.1 内核参数调优

调整线程栈大小
- 死锁可能因线程栈耗尽导致（如递归锁未释放），可通过ulimit -s调整线程栈上限。
```
ulimit -s 10240  # 设置线程栈大小为10MB  
```
启用抢占式内核
- 对于实时性要求高的系统，可编译内核时启用CONFIG_PREEMPT_RT，减少进程因资源等待导致的死锁风险。

5.2 程序设计最佳实践

避免嵌套锁

锁的获取顺序保持一致，避免线程 A 先锁 X 再锁 Y，线程 B 先锁 Y 再锁 X。

// 推荐：统一按资源编号顺序加锁  
if (resource_id(x) < resource_id(y)) {  
    pthread_mutex_lock(&x_lock);  
    pthread_mutex_lock(&y_lock);  
} else {  
    pthread_mutex_lock(&y_lock);  
    pthread_mutex_lock(&x_lock);  
}

使用超时锁

用pthread_mutex_timedlock替代pthread_mutex_lock，避免永久阻塞。

struct timespec timeout = {time(0) + 5, 0};  // 超时5秒  
if (pthread_mutex_timedlock(&lock, &timeout) == ETIMEDOUT) {  
    // 处理锁获取超时，避免死锁  
}

最小化锁持有时间

减少锁的作用域，仅在必要时持有锁。

// 反例：锁持有期间执行耗时操作  
pthread_mutex_lock(&lock);  
data = complex_calculation();  // 耗时操作，应在锁外执行  
save_to_database(data);  
pthread_mutex_unlock(&lock);  

// 优化：提前计算数据  
data = complex_calculation();  
pthread_mutex_lock(&lock);  
save_to_database(data);  
pthread_mutex_unlock(&lock);

5.3 典型案例：Nginx 进程死锁排查

现象：Nginx 响应变慢，部分请求超时。
排查步骤：
1. 通过ps -ef | grep nginx发现 worker 进程 CPU 占用率异常低，疑似阻塞；
2. 用pstack查看某 worker 进程的线程栈，发现多个线程卡在pthread_mutex_lock调用，等待同一把锁；
3. 分析代码发现，多个模块同时操作共享配置文件，锁竞争激烈，导致死锁；
解决方案：
- 将共享配置文件改为只读，重新加载时通过原子替换实现，避免写锁竞争；
- 对锁进行分层设计，细粒度锁替代粗粒度锁。

六、死锁与相关概念的区别

概念	定义	核心区别
死锁	进程互相等待资源，永久阻塞	所有进程处于阻塞状态，无进展
饥饿	进程因资源分配策略不公，长期无法获得资源	进程处于就绪状态，但调度器始终不分配资源
活锁	进程未阻塞，但因互相谦让导致无法推进（如两人过独木桥反复让路）	进程处于运行 / 就绪状态，但无用功，浪费 CPU 资源