加锁顺序不一致会导致死锁，因其使线程相互等待对方持有的锁；预防关键是所有线程按相同全局顺序（如地址升序）获取锁，并用std::lock原子锁定多锁。
为什么加锁顺序不一致会导致死锁
死锁最常见原因是多个线程以不同顺序获取同一组互斥锁。比如线程 A 先锁 mutex_a 再锁 mutex_b，而线程 B 反过来先锁 mutex_b 再锁 mutex_a —— 一旦 A 持有 mutex_a、B 持有 mutex_b，双方都在等对方释放，就卡死了。
预防的核心不是“避免上锁”，而是“让所有线程按相同全局顺序获取锁”。这不需要额外算法或检测，只靠约定和代码约束就能生效。
- 给所有互斥量定义唯一、可比较的标识（比如地址、枚举值或字符串名），并强制按该顺序调用
std::lock或手动 lock - 永远不要混合使用
mutex.lock()和std::lock()：前者不保证原子性，后者能一次性锁定多个且规避死锁 - 若必须分步加锁（如条件判断后才决定是否锁第二个），应确保所有路径遵循同一顺序，且已持锁不可被阻塞等待另一把锁
用 std::lock + std::lock_guard 组合安全锁定多把互斥量
std::lock 是 C++11 提供的原子多锁函数，它内部使用“回退重试”策略，确保不会因加锁顺序不同导致死锁。配合 std::lock_guard 的 std::defer_lock 构造方式，能精确控制锁的生命周期。
错误写法：mutex_a.lock(); mutex_b.lock(); —— 中间可能被中断或抛异常，导致只锁了一把；正确做法是统一交给 std::lock 管理。
立即学习“C++免费学习笔记（深入）”；
std::mutex mutex_a, mutex_b; // 正确：一次性尝试获取两把锁，失败则全部不锁 std::lock(mutex_a, mutex_b); std::lock_guard<std::mutex> guard_a(mutex_a, std::defer_lock); std::lock_guard<std::mutex> guard_b(mutex_b, std::defer_lock); // 注意：guard_a/guard_b 此时已绑定，但未接管所有权（defer_lock） // 实际上 std::lock 已完成加锁，guard 只负责析构时解锁
如何为互斥量定义全局唯一排序规则
当锁的数量多、分散在不同类或模块中时，靠人工记住顺序容易出错。一个轻量级但可靠的方案是用互斥量地址作排序依据 —— 地址天然可比、全局唯一、无需额外维护。
注意：地址比较只用于排序，不用于业务逻辑；且需确保互斥量生命周期长于所有使用它的线程（即不能是栈上临时对象）。
- 封装一个工具函数
lock_in_order，接受任意数量的std::mutex*，按地址升序调用std::lock - 避免对
std::mutex对象取地址再解引用操作（如&m后传入），应直接传指针变量或std::addressof(m)防止代理对象干扰 - 如果互斥量属于对象成员，建议将锁顺序逻辑下沉到该类的公共接口中，而非由调用方自行排序
哪些场景下这种预防机制会失效
按地址排序+std::lock 能解决“纯互斥量竞争”类死锁，但对更复杂资源依赖无能为力。比如：
- 持有
std::mutex的同时，又去等待一个条件变量std::condition_variable，而该条件变量的谓词依赖另一个未被纳入排序的锁 —— 这属于逻辑耦合，不是锁顺序问题 - 跨进程资源（文件锁、数据库行锁）无法用
std::lock统一管理，需依赖外部协调机制 - 递归锁（
std::recursive_mutex）虽允许同一线程重复加锁，但若与其他普通锁混用且顺序不一致，仍可能死锁 - 忘记在异常路径中释放锁（比如没用 RAII），会导致后续所有尝试获取该锁的线程永久阻塞 —— 这不是死锁，但表现类似，且更难排查
真正麻烦的从来不是“怎么加锁”，而是“哪些资源该一起锁、哪些不该、边界在哪”。地址排序只是起点，关键还是设计阶段就厘清资源依赖图。
