锁层次结构是为互斥锁定义全局唯一递增序号并强制按序加锁的编码约束，可消除循环等待从而预防死锁；其核心是编译期/设计期规避而非运行时检测，违反顺序即终止程序。
什么是锁层次结构，它为什么能预防死锁
锁层次结构本质是给所有互斥锁（std::mutex）人为定义一个全局唯一、不可逆的序号，要求线程必须按序号从小到大依次加锁，禁止跳级或逆序获取。只要所有代码都遵守这一规则，就不可能出现循环等待——而循环等待是死锁四个必要条件之一。
关键点在于：不是靠运行时检测，而是靠编码约束把死锁扼杀在设计阶段。一旦违反层次顺序（比如先锁 mutex_b 再锁 mutex_a，而 mutex_a 层级更低），程序应立即中止或报错，而不是侥幸运行。
如何为 mutex 分配并强制执行层级编号
最直接的方式是封装 std::mutex，带一个 level 成员，并在 lock() 时检查调用栈中已持有的锁是否都满足层级递增。但更轻量且实用的做法是：用一个线程局部变量记录当前已持锁的最大层级，每次加锁前做断言。
- 定义全局常量层级，例如：
constexpr int kResourceALevel = 1;、constexpr int kResourceBLevel = 2; - 每个锁实例关联其层级（可通过注释、命名约定，或封装类存储）
- 加锁前插入检查逻辑：
if (current_max_level >= target_level) { std::terminate(); // 或抛异常、日志后 abort } - 成功加锁后更新
current_max_level = target_level；解锁时需维护该变量（建议用 RAII 类自动管理）
实际编码中容易忽略的三个坑
层级规则看似简单，但落地时常见隐性破坏：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
动态创建的锁无法静态编号：比如按 ID 构造的
std::map<int, std::mutex>，不同 ID 对应的锁层级必须可推导（如 ID % N 映射到固定层级组），否则无法验证 - 嵌套调用导致间接逆序：函数 A 锁层级 3 后调用函数 B，而 B 内部又尝试锁层级 2 —— 这属于逻辑错误，必须拆分或重构，不能靠“B 不知道 A 已持锁”来开脱
-
std::unique_lock / std::shared_lock 的延迟构造绕过检查：若先声明
std::unique_lock<std::mutex> lk;，再调用lk.lock()，此时检查点可能遗漏。应统一用带检查的封装锁类型，或禁止裸lock()调用
一个最小可行封装示例（C++17）
以下不是通用库，而是说明核心机制如何嵌入真实代码：
struct CheckedMutex {
std::mutex mtx;
const int level;
CheckedMutex(int l) : level(l) {}
void lock() {
static thread_local int current_max = 0;
if (level <= current_max) {
std::cerr << "Deadlock risk: trying to lock level "
<< level << " while holding >= " << current_max << "\n";
std::terminate();
}
mtx.lock();
current_max = level;
}
void unlock() {
static thread_local int current_max = 0;
mtx.unlock();
// 注意：这里不降 current_max，因为 unlock 可能不在同作用域；
// 更健壮做法是用 RAII wrapper 在析构时恢复
}
};
真正工程中，unlock() 的层级回退必须由 RAII 完成，否则多层嵌套下 current_max 会永久卡住。这个细节恰恰是多数人抄完示例就跑，结果在线上偶发死锁的根源。
