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<std::mutex> lk1(m1, std::defer_lock); std::unique_lock<std::mutex> 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></: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，它们能捕获部分锁序违规和递归加锁
std::scoped_lock 简化了编码，但没消除对锁依赖图的理解要求。 
