层次锁能避免死锁，因其强制线程按全局统一层级顺序加锁，消除循环等待：构造时指定层级，lock前检查是否违反层级递增，违则抛出异常。
为什么层次锁能避免死锁
死锁发生的四个必要条件里，「循环等待」最常由多线程以不同顺序获取多个锁引发。层次锁通过强制所有线程按全局统一的锁层级顺序加锁，直接切断循环等待链——比如规定 mutex_A 层级为 1、mutex_B 为 2，那么任何线程都只能先锁 A 再锁 B，绝不允许反过来。
这不是靠运气或文档约定，而是用运行时检查+异常拦截来 enforce：一旦检测到当前线程试图获取比已持锁更低层级的锁，立即抛出 std::logic_error，让问题在开发/测试阶段暴露，而不是等到线上偶发卡死。
如何实现带层级检查的锁包装类
核心是记录每个锁的层级编号，并在线程局部存储当前已持锁的最高层级。每次调用 lock() 前做一次比较判断。
- 用
thread_local int current_max_level = 0记录本线程当前持有的最高锁层级 - 每个
HierarchicalMutex实例在构造时接收一个int level，并保存它 -
lock()中先检查：if (level - 检查通过后才真正调用底层
std::mutex::lock()，并更新current_max_level = level -
unlock()需要恢复current_max_level——但注意：无法精确知道释放的是哪一层，所以通常只在析构或显式unlock_all()时重置为 0（更健壮的做法是用 RAII 栈管理层级）
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
class HierarchicalMutex {
std::mutex mtx_;
const int level_;
public:
explicit HierarchicalMutex(int level) : level_(level) {}
void lock() {
if (level_ <= thread_local_max_level) {
throw std::logic_error("Deadlock prevention: trying to lock level "
+ std::to_string(level_) + " while holding >= that");
}
mtx_.lock();
thread_local_max_level = level_;
}
void unlock() {
mtx_.unlock();
// 简化处理：不追踪具体释放哪层，仅在作用域结束时由 RAII 清理
}
};
thread_local int thread_local_max_level = 0;
实际使用中必须遵守的约束
层次锁不是“设了层级就自动安全”，它依赖开发者主动维护层级设计和使用习惯。
- 所有互斥量必须用
HierarchicalMutex替代原生std::mutex，混用会绕过检查 - 层级数字必须全局唯一且单调——不能两个不同资源用相同
level，否则检查失效；也不建议跳着编号（如用 1 和 100），虽不报错但易误判优先级 - 锁的粒度要合理：层级基于资源访问关系，不是代码位置。例如数据库连接池和日志文件句柄明显属于不同抽象层，应分配不同 level；而两个同类型缓存分片若逻辑上可互换，则应共用同一 level 并用读写锁区分
- 不可递归加锁同一把
HierarchicalMutex：即使层级相同，lock()调用也会失败，因为thread_local_max_level已等于该 level。如需递归，得改用std::recursive_mutex并另行设计层级规则
调试时怎么快速定位违规加锁点
错误信息里只有层级数字，对大型项目不够直观。建议在抛异常前打日志，把当前线程 ID、已持锁层级、尝试获取的层级、以及（关键）调用栈地址记下来。
- 用
__builtin_return_address(0)（GCC/Clang）或_ReturnAddress()（MSVC）抓顶层调用地址 - 配合构建时开启
-g和运行时 addr2line 工具，能快速反查到哪行代码触发了违规 - 更进一步：把
HierarchicalMutex的构造参数从int改成const char* name，内部用字符串映射层级，异常信息里直接打出锁名，比如"db_pool_mutex" tries to acquire after "config_mutex"
真正的难点不在实现几行检查逻辑，而在于第一次给整个系统里的几十个锁排层级——这需要厘清数据流与依赖方向，稍有颠倒，预防机制本身就会成为 bug 来源。
