层次锁是通过人为约定互斥量加锁顺序来预防死锁的机制：为每个mutex分配静态层级编号，强制线程按编号从小到大获取锁，违反顺序则拒绝加锁，从而消除循环等待条件。
什么是层次锁，它为什么能预防死锁
层次锁不是语言内置机制，而是人为约定的加锁顺序规则：给所有互斥量（std::mutex）分配一个静态层级编号，要求线程必须按编号**从小到大**的顺序获取锁。一旦违反这个顺序（比如先锁 3 再锁 1），就主动拒绝加锁或抛异常——这样就能从源头上切断循环等待条件，从而预防死锁。
关键点在于：所有线程对同一组锁的获取顺序完全一致，不存在 A→B 同时 B→A 的竞争可能。实际中，层级通常用整数常量表示，比如 DB_MUTEX_LEVEL = 1、CACHE_MUTEX_LEVEL = 2、NETWORK_MUTEX_LEVEL = 3。
如何用 RAII 封装带层级检查的锁
直接用 std::mutex 无法做层级校验，需要封装一层。常见做法是定义一个 hierarchical_mutex 类，在构造时传入层级号，并在 lock() 前检查是否符合当前线程已持有的最高层级。
- 每个线程需维护自己的“当前最高锁层级”，可用
thread_local int current_level_ = 0 -
lock()里先比较传入层级和current_level_，若小于等于则抛std::logic_error("hierarchical_mutex violation") - 成功加锁后更新
current_level_；unlock()时还原为前一个层级（需记录历史，可用栈） - 必须配合 RAII（如
std::lock_guard的自定义版本），确保异常安全——否则unlock()漏掉会卡死整个线程
实际使用时最容易踩的三个坑
层次锁逻辑简单，但落地时几个细节极易出错：
立即学习“C++免费学习笔记（深入）”；
- 层级编号必须全局唯一且不可变，不能用地址哈希或运行时随机数生成——否则不同进程/加载顺序下层级关系不一致，反而引入新死锁
- 不要在锁已持有时调用
try_lock()或lock_shared()等变体，它们绕过层级检查；统一走封装后的lock()接口 - 跨模块协作时，各模块的层级定义要集中管理（比如放在头文件
lock_levels.h中），避免 A 模块认为FILE_LOCK_LEVEL == 5，B 模块却定义为6
一个最小可运行的层级锁示例
下面这段代码演示了核心逻辑，注意它只处理单次加锁（不支持递归、不处理 std::unique_lock 的延迟锁定）：
class hierarchical_mutex {
std::mutex mtx_;
const int level_;
thread_local static int current_level_;
public:
explicit hierarchical_mutex(int level) : level_(level) {}
void lock() {
if (level_ <= current_level_) {
throw std::logic_error("lock level " + std::to_string(level_) +
" <= current level " + std::to_string(current_level_));
}
mtx_.lock();
current_level_ = level_;
}
void unlock() {
mtx_.unlock();
// 实际中这里应恢复为上一个层级（需栈保存），简化版直接清零
current_level_ = 0;
}
};
thread_local int hierarchical_mutex::current_level_ = 0;
真正上线前，得补上 try_lock()、lock_guard 适配、多级嵌套支持——这些不是锦上添花，而是避免在复杂业务流中漏检的关键。
