c++oding="utf-8" ?>
gdb中通过info threads和thread apply all bt查找含__lll_lock_wait、pthread_mutex_lock或std::mutex::lock的栈帧可定位阻塞锁；重入死锁需检查是否误用std::mutex替代recursive_mutex；启用_GLIBCXX_DEBUG可捕获重复lock；ThreadSanitizer能检测锁序冲突。
用 gdb 查看线程阻塞在哪个锁上
死锁发生时，程序卡住不动，最直接的线索是哪些线程停在哪条 pthread_mutex_lock 或 std::mutex::lock 调用上。启动 gdb ./your_program，等卡住后按 Ctrl+C，执行：
info threads<br>thread apply all bt
观察每个线程的调用栈，重点找含 __lll_lock_wait、pthread_mutex_lock、std::mutex::lock 的帧——这些说明线程正等待获取锁。
识别重入锁（recursive mutex）误用为普通 mutex
重入导致死锁，往往是因为代码逻辑上“以为自己能重入”，但实际用了非递归锁。比如：std::mutex 不支持同一线程重复 lock()，第二次调用就会永久阻塞（不是抛异常）。常见场景：函数 A 锁了 mu 后调用函数 B，而 B 内部又尝试 mu.lock()。调试时注意：
- 检查所有
std::mutex是否被误用于可能递归调用的路径 - 若需重入，必须显式使用
std::recursive_mutex，且初始化/使用方式一致 -
std::unique_lock或std::lock_guard构造时不传入已持有的同把锁，否则也会卡在构造函数里
用 libstdc++ 的 debug mode 捕获重复 lock
GCC 的 libstdc++ 提供调试模式，能在运行时检测对 std::mutex 的非法重入。编译时加：
-D_GLIBCXX_DEBUG -g
然后运行。一旦同一线程对同一 std::mutex 重复调用 lock()，会立即 abort 并输出类似：
error: attempt to relock a non-recursive mutex
这比等死锁发生再查快得多。注意：该模式禁用部分优化，仅用于开发阶段；且只对标准库实现的 std::mutex 有效，不覆盖 pthread 原生锁。
避免靠猜——用 thread sanitizer 定位锁序冲突
重入只是表象，深层原因常是锁顺序不一致 + 重入掩盖了竞争。Clang/GCC 的 -fsanitize=thread 能在运行时报告锁的获取顺序冲突、释放未持有锁、以及“潜在死锁路径”。它不会直接标出“这是重入”，但会显示：
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
配合栈信息，能快速定位到哪两个函数以不同顺序持有了 mu1 和 mu2，而其中某个函数内部又因重入再次请求了已持有的锁。启用后务必关闭所有其他 sanitizer（如 ASan），避免干扰。
真正麻烦的不是重入本身，而是重入发生在间接调用链深处，比如回调、虚函数、或模板实例化后的内联函数里——这时候 bt 看不到完整上下文，得结合 finish 逐层返回，或者打条件断点在 std::mutex::lock 入口记录线程 ID 和调用栈。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
