加锁顺序不一致是死锁主因；应统一按地址升序加锁，用std::scoped_lock替代手动lock/unlock，必要时用std::timed_mutex配合超时检测。
用 std::mutex 时加锁顺序不一致是死锁主因
多线程死锁最常见的情况，就是两个线程以不同顺序获取同一组互斥量。比如线程 A 先锁 mtx_a 再锁 mtx_b，而线程 B 反过来先锁 mtx_b 再锁 mtx_a——只要它们交叉执行，就可能永久卡住。
排查时优先检查所有涉及多个 std::mutex 的临界区，确认加锁顺序是否全局统一。不要依赖“大概率不会同时发生”的侥幸心理。
- 把所有互斥量按地址排序后统一加锁：
std::scoped_lock能自动按地址升序加锁，避免手写顺序出错 - 禁用裸
lock()+unlock()配对；改用std::lock_guard或std::unique_lock管理生命周期 - 若必须动态决定锁顺序（如根据 ID 选 mutex），确保所有线程都按相同规则（如 ID 升序）决定加锁次序
死锁复现难？用 std::timed_mutex 主动暴露问题
生产环境里死锁往往只在高并发、特定调度下触发，常规测试很难抓到。与其等它卡住，不如让锁自己“喊话”。
std::timed_mutex 支持带超时的 try_lock_for，你可以在开发/测试阶段临时替换所有 std::mutex，并在超时后记录调用栈或 abort。
立即学习“C++免费学习笔记（深入）”；
if (!mtx.try_lock_for(200ms)) {
std::cerr << "Deadlock suspect at " << __FILE__ << ":" << __LINE__ << "\n";
std::abort();
}
- 上线前务必换回
std::mutex，std::timed_mutex有额外性能开销 - 超时值设为 100–500ms 较合理：太短易误报，太长拖慢响应
- 配合
backtrace()（Linux）或CaptureStackBackTrace（Windows）打印当前线程堆栈，快速定位争用点
GDB 调试挂起进程时，info threads 和 thread apply all bt 是关键
程序卡住后别急着重启，用 GDB 附加进去看线程状态。死锁线程几乎总是停在 pthread_mutex_lock 或 __lll_lock_wait 这类系统调用里。
运行以下命令能快速识别谁在等谁：
(gdb) info threads (gdb) thread apply all bt
- 找所有状态为
Blocked或停在__lll_lock_wait的线程 - 对比它们的调用栈末尾，看各自正在等待哪个
std::mutex对象地址 - 若线程 A 在等地址 0x7f...a0，线程 B 在等 0x7f...b0，而 A 持有 b0、B 持有 a0 —— 死锁闭环确认
静态分析工具能提前发现潜在锁序冲突
Clang 的 -Wthread-safety 和配套注解（如 GUARDED_BY、PT_GUARDED_BY）能在编译期捕获部分锁使用错误，但对跨函数的锁序问题无能为力。
更有效的是用 ThreadSanitizer（TSan）：它在运行时插桩检测锁序反转、未加锁访问等行为，且能给出具体冲突路径。
- 编译时加
-fsanitize=thread -g，运行时会输出类似 “WARNING: ThreadSanitizer: lock-order-inversion” 的报告 - TSan 不支持
std::shared_mutex或自定义锁类型，遇到需改用std::mutex临时绕过 - 性能下降约 5–10 倍，只适合测试环境启用；线上开启会显著拖慢吞吐
锁的嵌套层级、跨函数传递、与条件变量混用，都会放大死锁风险。越是“应该不会同时发生”的逻辑，越要当成重点怀疑对象。
