std::lock能原子性获取多个互斥量，需配合std::defer_lock使用；直接单独调用lock()易死锁，它内部按地址排序避免死锁，但不支持已上锁的mutex，且普通mutex不可重入。

std::lock 能同时锁多个互斥量，但必须配合 std::defer_lock 使用

直接对多个 std::mutex 调用 lock() 极易死锁，std::lock 的作用就是原子性地获取所有传入的锁，内部采用“先排序再尝试”的策略规避死锁。但它不接受已上锁的互斥量，所以每个互斥量都得用 std::defer_lock 构造，把“锁”这个动作交给 std::lock 统一调度。

• 错误写法：

  std::mutex m1, m2;
  m1.lock();  // ❌ 单独 lock 后再调 std::lock，行为未定义
  std::lock(m1, m2);

• 正确写法：

  std::mutex m1, m2;
  std::unique_lock lk1(m1, std::defer_lock);
  std::unique_lock lk2(m2, std::defer_lock);
  std::lock(lk1, lk2);  // ✅ 原子获取两把锁

• std::lock 是可重入的：如果某个互斥量已被当前线程持有（比如通过 std::recursive_mutex），它不会再次尝试加锁，但普通 std::mutex 不支持重入，仍需避免重复传入

锁序策略比 std::lock 更底层、更可靠，适合长期维护的代码

当锁的数量多、生命周期长或跨函数传递时，std::lock 不够用——它只解决“一次调用中多个锁”的竞争问题。真正的死锁预防依赖全局一致的锁获取顺序，比如按地址大小、按枚举 ID 或按资源层级排序。

• 推荐做法：为所有互斥量定义唯一且稳定的顺序标识，例如用 uintptr_t(&m) 强制转为地址值比较（注意：仅限同一进程内，且确保对象生命周期覆盖锁使用期）
• 危险操作：按变量名排序（如 “m1”
• 实用技巧：封装一个带序号的锁管理类，初始化时注册互斥量及其优先级，后续 acquire() 自动按序尝试（类似银行家算法的简化版）
• 性能影响：纯地址排序几乎无开销；若引入 map 查表或动态优先级，则有轻微延迟，但远小于死锁恢复成本

std::scoped_lock 是 C++17 起更简洁安全的替代方案

std::scoped_lock 是 std::lock + std::unique_lock 的语法糖，自动完成 defer 构造、加锁、RAII 释放三件事，代码更短、意图更清晰，且支持任意数量的互斥量（包括 0 个）。

• 等价但更优：

  std::mutex m1, m2;
  {
      std::scoped_lock lk(m1, m2);  // ✅ 自动 defer + lock + RAII
      // 临界区
  } // 自动 unlock

• 不支持运行时数量：模板参数在编译期确定，不能传 std::vector<:mutex> 这类动态容器
• 与 std::lock_guard 不兼容：后者只支持单锁，且不调用 std::lock，无法避免多锁死锁
• 注意兼容性：C++14 及以前只能用 std::lock + std::unique_lock 组合

容易被忽略的边界：锁升级、条件变量和异常安全

即使用了 std::scoped_lock，死锁仍可能发生在非显式加锁路径上，比如 std::condition_variable::wait 会临时释放锁并重新获取，若等待期间其他线程以不同顺序加锁，就可能打破原有锁序。

立即学习“C++免费学习笔记（深入）”；

• 条件变量等待必须用同一个 std::unique_lock（或 std::scoped_lock），不能拆成两个锁对象
• 锁升级（如读锁 → 写锁）无法用标准互斥量实现，需改用 std::shared_mutex 并严格遵守“先读再升，不降级”规则
• 异常发生时，RAII 保证锁释放，但若临界区内抛异常后逻辑跳转到另一段也持锁的代码，仍可能形成隐式锁序冲突
• 调试建议：启用 -D_GLIBCXX_DEBUG（GCC）或 AddressSanitizer + ThreadSanitizer，它们能捕获部分锁序违规和递归加锁