死锁的典型现象是界面假死且CPU占用率低，线程堆栈长时间停留在锁操作上；快速确认需用调试器检查多线程是否循环等待同一组互斥量，C++中最常见原因是手动加锁顺序不一致，推荐使用std::scoped_lock自动排序加锁。
死锁的典型现象和快速确认方法
界面假死但 CPU 占用率很低，线程堆栈长时间停留在 pthread_mutex_lock、std::mutex::lock 或 WaitForSingleObject（Windows）上，基本可判定是死锁。不是所有卡顿都是死锁——先用调试器挂起进程，查看主线程是否卡在锁操作，再检查其他工作线程是否也卡在同类锁调用上。
- Linux 下用
gdb -p <pid>后执行thread apply all bt，重点看多个线程是否循环等待同一组std::mutex或std::recursive_mutex - Windows 下用 Visual Studio 附加调试，打开「并行堆栈」窗口，观察线程阻塞点是否形成环形依赖
- 如果程序启用了
std::lock_guard或std::unique_lock但没用std::defer_lock等策略，容易掩盖加锁顺序问题
用 std::scoped_lock 避免加锁顺序不一致
手动控制多个互斥量加锁顺序出错，是 C++ 死锁最常见原因。比如线程 A 先 lock(mtx_a) 再 lock(mtx_b)，线程 B 反过来，就极易形成环形等待。
-
std::scoped_lock在构造时原子性地获取所有传入的互斥量，内部自动按地址排序加锁，彻底规避顺序问题 - 替代写法：
std::scoped_lock lk(mtx_a, mtx_b);比手写mtx_a.lock(); mtx_b.lock();安全得多 - 注意：不能用于
std::recursive_mutex和std::shared_mutex，它们不满足Lockable要求；若需递归或读写锁，必须自行保证全局加锁顺序
检测死锁的编译期和运行期辅助手段
靠人工审代码很难发现潜在死锁，尤其在模块边界模糊或跨线程回调频繁时。需要工具链介入。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Clang/GCC 编译时加
-D_GLIBCXX_DEBUG（libstdc++）或启用 libc++ 的 debug mode，部分实现会在std::mutex::lock重复调用时报resource_deadlock_would_occur - Linux 下可临时链接
libpthread的 deadlock-detecting 版本（如某些嵌入式 glibc 补丁），但生产环境慎用 - 更实用的是在关键锁封装层加日志：记录锁名、线程 ID、加锁前时间戳；配合脚本分析日志中「某线程持锁 A 等待 B，另一线程持 B 等待 A」的模式
UI 线程被阻塞的特殊处理原则
Qt 或 Win32 程序中，主线程（UI 线程）一旦进入耗时锁区，整个界面就无法响应消息循环，用户感知为“假死”。这不是死锁的必要条件，但会放大影响。
立即学习“C++免费学习笔记（深入）”；
- 绝对禁止在 UI 线程中直接调用
std::mutex::lock等可能长期阻塞的操作；应改用std::mutex::try_lock+ 重试/队列化，或把临界区逻辑移到工作线程 - Qt 中避免在
QMainWindow槽函数里锁共享数据结构；改用QMetaObject::invokeMethod把修改转发到专用 worker 对象 - Win32 下不要在
WndProc或OnPaint中调用WaitForMultipleObjects等同步等待 API
真正难排查的，是那些只在特定负载下才暴露的锁竞争路径——比如两个线程几乎同时触发回调，又恰好以相反顺序访问三个以上互斥量。这时候静态分析和日志都可能漏掉，得靠压测+堆栈采样反复验证。
