扫码关注
CONCURRENCY · 线程同步
这是Linux/C++嵌入式面试的经典题，既考并发基础，也能检验真实调试方法。
先给结论
常见死锁是线程持有部分资源后相互等待，形成环形依赖。排查要明确谁持有哪把锁、谁在等待什么，再统一锁顺序或缩小锁粒度。
① 面试官到底在考什么？
很多程序偶发卡住，CPU占用却不一定很高。与忙循环不同，死锁线程可能都阻塞在互斥锁等待上，日志也可能停在特定位置。
② 工程思路：按这个顺序展开
01 / 先定位卡住的线程
保留进程ID、线程信息与故障时刻，用gdb的thread apply all bt、/proc及日志查看各线程停在哪个等待点。
02 / 还原持锁和等待关系
画出线程—锁之间的依赖，重点检查是否存在A先拿锁1后拿锁2、B却反着拿锁的情况。也检查遗漏解锁、异常路径及自锁。
03 / 修复要防复发
统一全局加锁顺序，尽量缩短临界区，避免持锁调用不受控的外部接口；需要时采用trylock/超时和结构化锁管理，但超时不是消除设计问题的替代品。
③ 常见失分点
一看到线程卡住就说“肯定死锁”，没有排除I/O阻塞和等待条件未满足
认为改成递归锁就能彻底解决所有死锁
只在线上增加打印，却没有保存线程栈和复现场景
④ 面试时可以这样回答
“我先把问题区分为CPU忙循环、I/O阻塞和锁等待。如果怀疑死锁，就抓所有线程栈，找互斥锁等待链并还原持锁顺序。修复一般是统一锁顺序、减少嵌套持锁，随后用压力与并发场景回归。”
面试官可能继续追问
如果只有一个线程，它还可能因为锁而把自己卡住吗？
