死锁本质是资源获取顺序不一致，解决关键是统一加锁顺序；优先用std::scoped_lock处理多锁，单锁用std::lock_guard，需灵活控制时用std::unique_lock配合条件变量。
死锁根本不是锁的问题，而是资源获取顺序不一致
死锁在 C++ 多线程中几乎总是因为多个线程以不同顺序请求同一组互斥量（std::mutex）导致。比如线程 A 先锁 mtx_a 再锁 mtx_b，而线程 B 反过来先锁 mtx_b 再锁 mtx_a——只要两个线程执行节奏稍有交错，就卡死。
解决思路不是换锁类型，而是统一加锁顺序。常见做法包括：
- 给所有互斥量定义全局唯一序号，按序号从小到大加锁（用
std::scoped_lock可自动完成） - 避免在持有锁期间调用可能获取其他锁的函数（尤其是第三方或虚函数）
- 绝不手动调用
lock()/unlock()；裸调用是死锁温床
std::lock_guard 适合“进作用域即锁，出作用域即放”的简单场景
std::lock_guard 是最轻量、最安全的 RAII 锁包装器，构造时立即加锁，析构时必然释放，不可转移、不可复制、不可延迟加锁。
它适用于：单个 mutex 的短临界区、不需要条件等待、不涉及多个锁的同步。
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx;
void safe_update() {
std::lock_guard<std::mutex> guard(mtx); // 构造即 lock()
// ... 临界区操作
} // 出作用域，guard 析构，自动 unlock()
注意：lock_guard 不支持 try_lock()、不支持 unlock() 提前释放、不能用于 std::condition_variable::wait() ——这些都得换 std::unique_lock。
std::unique_lock 是灵活但需更谨慎的锁管理器
std::unique_lock 支持延迟加锁、手动解锁、条件变量配合、可移动（用于返回锁、传入函数），但灵活性带来责任：忘记 lock() 或重复 unlock() 会引发未定义行为。
典型误用：
- 声明后没调
lock()就进临界区 → 数据竞争 - 调了
unlock()后又让其析构 → 二次 unlock → UB - 传给
wait()后没检查条件就继续用被临时释放的锁 → 逻辑错乱
正确用法示例（配合条件变量）：
std::mutex mtx;
std::condition_variable cv;
bool ready = false;
// 等待方
void wait_for_ready() {
std::unique_lock<std::mutex> ulock(mtx);
cv.wait(ulock, []{ return ready; }); // wait 内部会 unlock + 唤醒后重新 lock
// 此处 ulock 已重新持有 mtx，可安全访问 shared data
}
// 通知方
void set_ready() {
std::lock_guard<std::mutex> guard(mtx);
ready = true;
cv.notify_one();
}
优先用 std::scoped_lock 解决多锁死锁
C++17 引入的 std::scoped_lock 是处理多个互斥量的首选：它原子性地获取所有锁，内部自动按地址排序（或使用 ADL std::lock 协议），彻底规避因加锁顺序不一致导致的死锁。
对比 lock_guard（只支持一个锁）和手写多 lock()（易出错），scoped_lock 更简洁可靠：
std::mutex mtx_a, mtx_b;
void transfer(int amount) {
// 安全：自动避免死锁
std::scoped_lock lock(mtx_a, mtx_b);
// ... 同时操作两个资源
}
注意：scoped_lock 构造失败（如某 mutex 不可 lock）会抛 std::system_error，且不提供 try_lock 变体——如需非阻塞，应改用 std::try_to_lock_t + unique_lock 组合。
真正容易被忽略的是：即使用了 scoped_lock，如果临界区内又间接触发了其他锁（比如调用了一个你没看源码的库函数），死锁依然可能发生。锁管理只是工具，资源访问契约才是关键。
