层次锁排序是为所有互斥锁分配全局唯一递增层级编号并强制线程按编号从小到大顺序加锁的机制，它通过消除循环等待（死锁四条件之一）来预防死锁；关键在于全局一致、不可变的单调递增加锁顺序，配合RAII封装与线程局部层级栈校验。
什么是层次锁排序，为什么它能预防死锁
层次锁排序不是让锁自己“排序”，而是要求程序员给所有锁定义一个全局唯一的层级编号，每次按编号从小到大顺序加锁。只要所有线程都遵守这个顺序，就不可能出现 A 等 B、B 等 A 的循环等待——死锁的四个必要条件之一就被打破了。
关键点在于：顺序必须是全局一致的、不可变的，且加锁路径必须严格单调递增（不能跳着加，也不能倒着加）。
- 层级编号通常用
int或enum表示，比如LOCK_LEVEL_ACCOUNT = 1、LOCK_LEVEL_TRANSACTION = 2 - 不能靠运行时动态决定顺序（比如按指针地址排序），否则不同线程可能得出不同结论
- 同一个对象上的多个锁（如读锁/写锁）也要归入同一层级，避免内部绕过规则
如何用 RAII 封装带层级检查的锁
直接裸调用 std::mutex::lock() 很难强制执行顺序，所以得包装一层，在构造时检查是否符合层级规则。典型做法是维护一个线程局部的已持有锁层级栈（thread_local std::vector<int></int>），每次尝试获取新锁前校验新层级 > 栈顶层级。
class HierarchicalLock {
static thread_local std::vector<int> held_levels;
const int level_;
std::mutex& mtx_;
public:
HierarchicalLock(std::mutex& m, int level) : level_(level), mtx_(m) {
if (!held_levels.empty() && level_ <= held_levels.back()) {
throw std::logic_error("Lock level violation: " +
std::to_string(level_) + " <= " +
std::to_string(held_levels.back()));
}
held_levels.push_back(level_);
mtx_.lock();
}
~HierarchicalLock() {
mtx_.unlock();
held_levels.pop_back();
}
};
- 注意
thread_local是必须的，否则多线程会互相干扰 - 抛异常比静默失败更安全——宁可崩溃也不留隐患
- 不要在析构里做复杂逻辑，尤其别再调其他锁，否则可能二次触发检查
实际使用中容易踩的三个坑
这套机制看似简单，但落地时经常因为边界情况失效：
立即学习“C++免费学习笔记（深入）”；
- 忘记初始化
thread_local std::vector—— C++11 起默认构造为空，但某些旧编译器或静态链接场景下可能未初始化，建议显式写thread_local std::vector<int> held_levels{}; - 跨函数传递锁对象（比如把
HierarchicalLock作为参数传入）导致析构时机错乱，应只在作用域内创建、不转移所有权 - 与第三方库混用：如果某库内部也用了
std::mutex但没遵循你的层级，整个机制就形同虚设。这时要么封装它的 API，要么单独划出“无序区”并严格隔离
层级编号设计不是随便拍脑袋的事
编号本身没有语义，但设计不合理会导致后续扩展困难或误用：
- 预留空隙：比如账户锁用
10、交易锁用20，中间留出15给未来“账户余额快照锁”这类衍生锁 - 按数据依赖关系排：上游数据锁层级低，下游计算锁层级高（例如先锁用户，再锁其订单，再锁订单明细）
- 避免用宏定义硬编码层级，推荐用
constexpr enum class LockLevel { Account = 10, Order = 20, Item = 30 };，便于 IDE 跳转和类型检查
真正麻烦的从来不是写几行锁检查代码，而是让整个团队对“哪个锁该在哪一层”达成共识，并在新增模块时持续维护这个秩序。一旦层级表变成没人敢改的祖传配置，说明机制已经从预防工具退化成维护负担。
