生产环境死锁需通过gdb脚本从core dump提取各线程锁持有/等待地址，构建有向图并检测环；因linux无现成命令直接输出锁依赖关系，须结合符号表、栈回溯与地址交叉比对实现自动化归因。
生产环境出现死锁时，gcore 或 kill -6 生成的 core dump 本身不带线程等待关系，必须结合符号表和栈回溯才能定位循环等待链——单纯用 gdb core 看堆栈，大概率只看到一堆线程卡在 pthread_mutex_lock，看不出谁等谁。
怎么从 core dump 提取所有线程的锁持有/等待状态
Linux 下没有现成命令直接输出“线程 A 持有 mtx1、等待 mtx2”，但可通过 gdb 脚本批量提取关键信息：
- 先用
gdb -batch -ex "thread apply all bt" -p <pid></pid>抓全量调用栈（若进程还活着）；若只有 core，则用gdb <binary> core -batch -ex "thread apply all bt"</binary> - 重点过滤含
std::mutex::lock、pthread_mutex_lock、__lll_lock_wait的栈帧，它们大概率是阻塞点 - 对每个线程，再执行
info registers+x/20xg $rsp查看寄存器和栈顶，找是否存有std::mutex*地址（需符号表支持） - 若二进制带调试信息，可用
print *(std::mutex*)0x7f8a12345678尝试打印互斥量状态（但std::mutex内部无公开字段，实际常只能靠地址交叉比对）
用 Python 脚本自动识别循环等待链
人工翻几十个线程的栈太慢。核心逻辑是：把每个线程的「持有锁地址」和「阻塞在哪个锁地址」抽出来，建有向图，检测环。
- 输入：gdb 输出的文本，每段以
Thread <n></n>开头，含bt和可能的info registers结果 - 正则匹配锁地址：例如
std::mutex::lock\(\) at.*\+(0x[0-9a-f]+)或pthread_mutex_lock\((0x[0-9a-f]+) - 对每个线程，记录
held = [addr1, addr2]（从 lock_guard 构造或 try_lock 成功推断），waiting_on = addrX（从最顶层阻塞调用中提取） - 用
networkx建图：held[i] → waiting_on[i]，然后跑nx.simple_cycles()找环 - 注意：同一互斥量地址在不同线程中应视为同一节点，否则图会失效
为什么不能只依赖 ThreadSanitizer 或 Helgrind
它们是动态检测工具，但生产环境通常禁用：
-
-fsanitize=thread会让性能下降 5–20 倍，且要求所有依赖库也带 TSan 支持，线上几乎不可行 - Helgrind 依赖 Valgrind，运行时开销更大，且无法 attach 到已卡死的进程，只能用于复现阶段
- 二者都检测“潜在”竞争或死锁，但真实死锁发生后，dump 是唯一留下的现场证据
- 它们不解决「已经发生的死锁如何快速归因」，而脚本分析 dump 是事后诊断的刚性需求
真正难的不是写脚本，而是让脚本能稳定识别出「哪个地址对应哪个逻辑锁」——这需要构建锁地址到变量名的映射表（比如通过 nm -C <binary> | grep mutex</binary> 配合 DWARF 信息），否则脚本输出的只是 0x7f... 这样的数字，仍需人工对照源码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
