死锁的本质是争夺顺序不一致与持有资源后继续等待导致的闭环，典型如两线程反序申请mtx1和mtx2：a持mtx1等mtx2，b持mtx2等mtx1，满足互斥、持有并等待、不可剥夺、循环等待四条件。
死锁的本质不是资源不够，而是多个线程对共享资源的**争夺顺序不一致**，加上**持有资源后继续等待**，最终形成互相卡住的闭环。
交叉竞争变量资源的具体过程
典型场景是两个线程分别以相反顺序申请两个互斥量（如 mtx1 和 mtx2）：
- 线程 A 先成功获取 mtx1，然后尝试获取 mtx2；
- 线程 B 同时成功获取 mtx2，再尝试获取 mtx1；
- 此时 A 持有 mtx1 等 mtx2，B 持有 mtx2 等 mtx1 —— 双方都不释放已有锁，也无法前进。
这种“各拿一半、互等另一半”的状态，就是交叉竞争引发的死锁起点。
四个必要条件如何同时被触发
上述例子中，以下四点全部满足，缺一不可：
- 互斥条件：mtx1 和 mtx2 都是排他锁，不能被两个线程同时持有；
- 持有并等待：A 拿着 mtx1 不放，还去要 mtx2；B 同理；
- 不可剥夺：C++ 的 std::mutex 不支持强制释放，只能由持有者主动 unlock；
- 循环等待：A → mtx2 → B → mtx1 → A，构成一个等待环。
为什么变量资源特别容易出问题
变量本身不是资源，但保护它的同步机制（如 mutex、spinlock、atomic flag）才是。问题常出现在：
- 多个类成员变量各自配独立锁，但业务逻辑跨对象调用时未统一加锁顺序；
- 函数内部局部加锁，不同调用路径导致锁获取次序随机；
- 全局变量 + 多线程读写 + 手动加锁，而锁粒度与访问范围不匹配。
避开交叉竞争的实用办法
核心思路是打破“循环等待”或“持有并等待”：
- 所有线程按固定编号顺序申请锁（例如总是先锁 addr1 再锁 addr2）；
- 用 std::lock(mtx1, mtx2) 一次性尝试获取多个锁，避免部分成功；
- 改用带超时的 try_lock_for，失败则回退并释放已持锁；
- 减少锁数量：把多个变量合并到一个结构体，用单把锁保护，或改用无锁数据结构。
