最直接方法是用 gdb -p <pid> 查线程堆栈：info threads 看状态，thread apply all bt 打印调用栈，重点检查 std::lock_guard、scoped_lock 或裸 lock() 调用位置；配合 set backtrace past-main 避免截断；无源码行号需重新 -g 编译。
用 gdb 查卡死进程的线程堆栈最直接
程序已经僵住？别重启，先用 gdb -p <pid> 进去，执行 info threads 看所有线程状态。如果多个线程都停在 pthread_mutex_lock 或 std::mutex::lock()，基本就是死锁了。
接着用 thread apply all bt 打印全部调用栈，重点找 std::lock_guard 构造、std::scoped_lock 构造或裸 mtx.lock() 调用行——这些就是实际加锁位置。注意某些 glibc 版本下 bt 可能截断，可先执行 set backtrace past-main 再试。
常见陷阱：
- 堆栈里只看到系统调用（如
__lll_lock_wait），没你自己的代码行号？说明没带-g编译，重编再试 - 线程显示在
std::this_thread::sleep_for之类地方？那不是死锁，是逻辑阻塞，别误判 - 看到
std::condition_variable::wait卡住？检查是否漏发notify，和死锁无关
用 ThreadSanitizer 编译时捕获锁序颠倒
ThreadSanitizer（TSan）不是运行时“检测死锁”，而是发现导致死锁的前置错误：锁获取顺序不一致。它能在程序跑起来几秒内报出 WARNING: ThreadSanitizer: lock-order-inversion，并精准定位到两处加锁语句的源码行。
立即学习“C++免费学习笔记（深入）”；
启用方式很简单：
- GCC/Clang 加编译选项：
-fsanitize=thread -g -O1 - 必须链接 TSan 运行时（通常默认包含）
- 不要加
-O2或更高优化，否则可能漏报
它不依赖你改代码，也不需要进程卡死，适合 CI 阶段常态化扫描。但注意：它无法发现“所有线程都等同一把锁”的饥饿问题，只抓循环等待链的起点。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
用 std::scoped_lock 和 std::lock 主动规避死锁
检测只是补救，真正省心的做法是让死锁根本构造不出来。C++17 起，所有需要多锁的场景，优先用 std::scoped_lock：
std::mutex mtx_a, mtx_b; std::scoped_lock lock(mtx_a, mtx_b); // 安全：内部按地址排序，原子获取
如果必须用 std::unique_lock（比如要延迟加锁或配合条件变量），就改用 std::lock + std::adopt_lock 组合：
std::unique_lock<std::mutex> lk1(mtx_a, std::defer_lock); std::unique_lock<std::mutex> lk2(mtx_b, std::defer_lock); std::lock(lk1, lk2); // 原子性尝试获取两个，失败抛异常，不会只锁一个
绝对避免手动写 mtx_a.lock(); mtx_b.lock(); 这种裸调用——顺序错、中途异常、提前 return，都会让锁状态失控。
线上环境慎用 valgrind --tool=helgrind
helgrind 确实能报告 possible deadlock，但它代价太高：运行速度降 5–10 倍，内存翻倍，且要求 -g -O0 编译。线上服务扛不住，也压不出偶发性死锁（比如只在高负载调度延迟时才触发）。
它唯一靠谱的使用场景是：本地复现一个**稳定可触发**的死锁路径（比如两个线程固定 sleep 后抢锁），然后快速验证修复是否生效。报错位置常在 pthread 底层，得靠堆栈往上翻 3–4 层才能看到你代码里的锁变量名，别指望它一键定位。
真正线上可用的方案其实是 std::timed_mutex + 超时日志：把关键锁换成带超时的，try_lock_for 失败时记录 "waited 500ms for mtx_user_db"，积累几次就能反向推导出哪条路径在堵。
