std::lock能避免死锁，因其原子性地同时获取多个互斥量，采用无序尝试与回退重试策略，彻底消除循环等待；失败时自动回滚已获锁，确保要么全成功、要么全不锁。
std::lock 为什么能避免死锁
std::lock 的核心价值不是“加锁”，而是**原子性地同时获取多个互斥量，且内部采用无序尝试 + 回退重试策略**。它不按传入顺序依次 try_lock，而是用类似“先抢后协调”的方式，彻底规避因线程间加锁顺序不一致导致的循环等待——而这正是死锁的必要条件之一。
常见错误是手动写 mtx1.lock(); mtx2.lock();，一旦线程 A 拿着 mtx1 等 mtx2，线程 B 拿着 mtx2 等 mtx1，立刻死锁。而 std::lock 会保证：要么全部成功，要么一个都不上锁（失败时所有已尝试的锁都会被回滚）。
- 只接受可调用
try_lock()的互斥量类型（如std::mutex、std::timed_mutex） - 若任一互斥量不可用，
std::lock会释放已获得的锁，并重新调度尝试顺序，不是简单抛异常 - 不适用于
std::shared_mutex或自定义锁（除非显式提供try_lock成员）
std::lock 的正确调用姿势
必须配合 std::defer_lock 构造的 std::unique_lock 使用，不能直接对已上锁的互斥量调用 std::lock —— 否则行为未定义。
典型安全模式：
立即学习“C++免费学习笔记（深入）”；
std::mutex mtx1, mtx2; std::unique_lock<std::mutex> lk1(mtx1, std::defer_lock); std::unique_lock<std::mutex> lk2(mtx2, std::defer_lock); std::lock(lk1, lk2); // ✅ 安全：两个 unique_lock 都处于未持有状态 // 此时 lk1.owns_lock() && lk2.owns_lock() 均为 true
- 传入的
std::unique_lock必须以std::defer_lock初始化，否则构造时就可能阻塞或死锁 - 支持任意数量参数（C++17 起），但超过 2 个时建议封装成容器再用
std::scoped_lock - 不要混用裸
mutex.lock()和std::lock—— 锁状态混乱会导致未定义行为
std::scoped_lock 是更现代的替代方案
C++17 引入的 std::scoped_lock 是 std::lock + std::unique_lock 的语法糖，自动处理 defer 和 RAII，语义更清晰、出错率更低。
std::mutex mtx1, mtx2;
{
std::scoped_lock lock(mtx1, mtx2); // ✅ 自动调用 std::lock + RAII 管理
// 临界区
} // 自动解锁，无需手动管理 unique_lock 生命周期
-
std::scoped_lock内部仍调用std::lock，所以同样具备死锁免疫能力 - 不支持超时（
std::scoped_lock没有try_lock_for变体），需要超时时仍得退回std::unique_lock+std::try_lock - 若需动态数量的锁（比如 vector
），只能用 std::lock手动展开，std::scoped_lock不支持运行时参数个数
容易被忽略的边界情况
死锁免疫只在“完全由 std::lock 或 std::scoped_lock 控制的锁集合”内成立。一旦混入外部同步机制，保护就失效了。
- 嵌套调用：函数 A 调用
std::lock(mtx1, mtx2)，函数 B 在持有mtx1时调用std::lock(mtx2, mtx3)→ 仍可能死锁（mtx1不在 B 的std::lock参数中） - 与条件变量配合时：
std::condition_variable::wait会释放锁并重入，此时其他线程若用不同顺序加锁，仍可能引发竞争，需统一约定锁顺序 - 跨线程共享锁对象本身：若一个线程正在析构
std::mutex，另一个线程调用std::lock→ UB，锁对象生命周期必须严格长于所有使用它的线程
真正难的从来不是调用哪个函数，而是确保所有涉及同一组资源的加锁路径，都落在同一个 std::lock 或 std::scoped_lock 调用里 —— 少一次封装，就多一分风险。
