死锁是多个线程永久阻塞在互相等待对方释放锁的状态；典型如线程a持mutex_a争mutex_b，线程b持mutex_b争mutex_a；正确做法是用std::lock或c++17的std::scoped_lock确保原子性加锁。
死锁是怎么发生的，不是代码卡住就是死锁？
死锁不是程序“变慢”或“卡半天”，而是两个或更多线程**永久阻塞在互相等待对方释放锁**的状态。典型场景是：线程 A 持有 mutex_a，想拿 mutex_b；同时线程 B 持有 mutex_b，想拿 mutex_a——谁也不让，谁都动不了。
常见错误现象包括：程序突然停在某处不动、CPU 占用率低但响应彻底停止、gdb 查看线程堆栈时发现多个线程都停在 pthread_mutex_lock 或 std::mutex::lock() 调用上。
- 只要涉及多个互斥量（
std::mutex）且加锁顺序不一致，风险就存在 - 即使只用一个
std::mutex，嵌套调用 + 异常路径也可能导致重复 lock（比如没用 RAII） -
std::lock_guard本身不解决多锁顺序问题，它只保证单个锁的自动释放
std::lock_guard 怎么用才真防死锁？
std::lock_guard 的核心作用是“异常安全地管理单个锁的生命周期”，不是万能死锁防火墙。它防的是“忘了 unlock”或“unlock 前抛异常”这类人为失误。
正确用法的关键在于：声明即加锁，离开作用域自动解锁，且不提供手动 unlock 接口。
立即学习“C++免费学习笔记（深入）”；
- 必须用
std::defer_lock配合std::lock才能安全处理多个 mutex——直接对多个std::lock_guard分别构造会引发竞态 - 错误写法：
std::lock_guard<:mutex> g1(mtx1); std::lock_guard<:mutex> g2(mtx2);</:mutex></:mutex>—— 这里g1和g2构造顺序不确定，极易触发死锁 - 正确写法：先
std::lock(mtx1, mtx2)（原子性获取所有锁），再用std::lock_guard带std::adopt_lock参数接管
std::mutex mtx1, mtx2; std::lock(mtx1, mtx2); // 一次性获取两个锁，内部有死锁避免算法 std::lock_guard<std::mutex> g1(mtx1, std::defer_lock); std::lock_guard<std::mutex> g2(mtx2, std::defer_lock); // 实际不用这么写 —— 更推荐下面这种： std::lock(mtx1, mtx2); std::lock_guard<std::mutex> g1(mtx1, std::adopt_lock); std::lock_guard<std::mutex> g2(mtx2, std::adopt_lock);
为什么 std::scoped_lock 是更好的选择？
C++17 引入的 std::scoped_lock 就是为简化多锁场景而生的，它把 std::lock + 多个 std::lock_guard 合并成一步，且默认采用死锁规避策略（如按地址排序加锁）。
相比手写 std::lock + std::adopt_lock，它更短、更不易出错、支持任意数量的互斥量。
-
std::scoped_lock构造时自动调用std::lock，失败会抛std::system_error - 不支持
std::defer_lock等策略参数，设计上就是“全有或全无” - 如果已有 C++14 项目，不能升级标准，就老实用
std::lock+std::lock_guard组合
std::mutex mtx1, mtx2;
{
std::scoped_lock lk(mtx1, mtx2); // 安全！自动规避死锁顺序
// 访问共享资源
} // 自动解锁
还有哪些地方容易漏掉导致死锁？
很多人以为用了 std::lock_guard 或 std::scoped_lock 就万事大吉，但实际工程中还有几个隐蔽高发点：
- 递归锁误用：
std::mutex不支持同一线程重复 lock，若函数 A 加锁后调用函数 B，B 又尝试 lock 同一把锁，直接死锁；该用std::recursive_mutex的地方没换 - 锁粒度太粗：整个函数体包在一个
std::scoped_lock里，期间调用外部函数（比如回调、日志、网络请求），而这些外部函数又可能间接申请别的锁 - 条件变量配合不当：
std::condition_variable::wait会临时释放锁，但唤醒后重新加锁——如果唤醒逻辑本身又依赖另一把锁，就可能形成环路 - 跨线程对象生命周期：一个线程正在析构持有锁的对象，另一个线程还在试图 lock 它——访问已销毁 mutex 行为未定义，部分平台表现为卡死
真正难的从来不是“怎么加锁”，而是“锁的边界是否和业务语义对齐”。多线程里最危险的不是 crash，是看似正常跑着，却在特定调度下永远等不到对方松手。
