std::lock通过固定内存地址升序加锁策略避免死锁，原子性协调多锁获取，失败时释放已获锁并重试；而手动加锁易因顺序不一致导致死锁。
std::lock 是怎么做到“同时加锁还不死锁”的
std::lock 本身不检测死锁，也不在运行时动态规避；它靠的是**固定顺序加锁策略**——对多个 std::mutex 对象，按内存地址升序尝试加锁。这个顺序是确定的、跨线程一致的，从而从根源上消除循环等待条件。
关键点在于：它不是“先抢一个再抢另一个”，而是原子性地协调多个互斥量的获取过程
std::lock 会释放已成功获取的锁，并重试（内部使用回退+重试机制），避免单个锁长期占用导致的间接阻塞。
std::lock 和手写 lock1 + lock2 的区别在哪
手动顺序加锁（比如先 mtx1.lock() 再 mtx2.lock()）极易因不同线程采用不同顺序而引发死锁。而 std::lock 强制所有调用者遵循同一顺序：
- 它把所有传入的
mutex指针转为地址，排序后依次尝试try_lock() - 只要任一锁失败，就对已成功的锁调用
unlock()，然后短暂让出（如std::this_thread::yield()），再重试整组 - 这个过程对用户透明，无需关心重试逻辑
std::mutex mtx1, mtx2; // 安全：std::lock 自动排序，不会因调用顺序不同而死锁 std::lock(mtx1, mtx2); // 危险：以下两行在不同线程中交叉执行极易死锁 mtx1.lock(); mtx2.lock(); // 线程 A mtx2.lock(); mtx1.lock(); // 线程 B
std::lock 的局限性和常见误用
它只解决“多 mutex 同时加锁”场景下的死锁问题，不适用于嵌套锁、递归锁、或混合使用 std::unique_lock 延迟构造等复杂情况。
- 传入的 mutex 必须支持
try_lock()（std::mutex、std::timed_mutex可以，但std::recursive_mutex不行） - 不能传入已处于锁定状态的 mutex，否则行为未定义
- 若某 mutex 被
std::unique_lock持有且处于 defer_lock 状态，需先确保其未被 lock，再传给std::lock - 性能上比单个
lock()略高开销，因为涉及地址比较、多次try_lock()和可能的重试
std::scoped_lock 是更现代的替代方案吗
是的。std::scoped_lock（C++17 起）在构造时调用 std::lock，并在析构时自动释放所有锁，兼具安全性和 RAII 语义。它比裸用 std::lock 更不容易出错：
- 无需手动配对
unlock()，避免异常路径下漏解锁 - 同样基于地址排序，死锁规避能力一致
- 模板参数推导更严格，编译期就能捕获不支持
try_lock()的类型
std::mutex mtx1, mtx2;
{
std::scoped_lock lk(mtx1, mtx2); // 构造即 lock，作用域结束自动 unlock
// ... 临界区
} // 这里自动 unlock，即使抛异常也安全
真正容易被忽略的是：地址排序依赖的是 mutex 对象本身的地址，不是指针值或包装器地址；如果通过指针或引用传入不同位置的 mutex 实例，排序结果依然稳定——但若在栈上临时构造 mutex 并传地址，就可能引入未定义行为。
