固定锁顺序能破循环等待，因为其直接消除死锁四条件中的“循环等待”：按地址、ID或字典序统一加锁，使线程A等B、B等A的闭环无法形成。
死锁不是“会不会发生”，是“什么时候触发”——只要两个线程以不同顺序申请同一组 std::mutex，且都已持有一个再等另一个，程序就会永久卡在 lock() 或 std::scoped_lock 构造里，CPU 占用归零，gdb 显示停在 __pthread_mutex_lock。
为什么固定锁顺序能破循环等待
死锁的四个必要条件中，“循环等待”最易被工程手段打破。而固定顺序（比如始终先锁地址小的、ID 小的、或按变量名字典序）直接让“线程 A 等 B、B 等 A”这个环无法形成。
- 所有跨资源操作前，对锁指针做
std::less<:mutex>{}(p1, p2)</:mutex>比较，统一按升序加锁 - 避免用裸指针/引用跨函数传锁——容易在调用链中丢失顺序控制权
- 不要依赖“逻辑上应该先动哪个”，而要用可判定、可复现的规则（如内存地址）
- 注意：
std::recursive_mutex不支持std::scoped_lock默认构造，若混用会编译失败
std::scoped_lock 是怎么防住顺序错误的
std::scoped_lock 不是靠“猜顺序”，而是内部调用 std::lock 实现的原子加锁：它会对传入的所有 std::mutex 指针排序（通常用地址），再按序尝试获取；若某一步失败，就释放已得锁并重试，直到全部成功或线程被中断。
- 写
std::scoped_lock lock(mtx_b, mtx_a);和std::scoped_lock lock(mtx_a, mtx_b);效果完全一样 - 它不支持
std::timed_mutex或std::shared_mutex（除非显式指定策略模板参数） - 析构时自动释放全部锁，没有
unlock()接口——想提前释放？说明你该拆分临界区了 - 和
std::unique_lock混用要小心：std::unique_lock可延迟加锁、可转移，但一旦和scoped_lock共享同一把锁，RAII 生命周期就难对齐
std::try_lock 适合什么场景，又容易栽在哪
当锁来自不同模块、无法约定全局顺序（比如插件系统或回调注入），std::try_lock 是唯一可控的退路。但它不是“加锁失败就跳过”，而是要求你手动管理回滚。
立即学习“C++免费学习笔记（深入）”；
-
std::try_lock返回-1表示至少一个锁失败，其余成功获取的锁**不会自动释放**，必须你显式调用mtx.unlock() - 别用
std::timed_mutex::try_lock_for替代——它只管单个锁，多个锁之间无协调，仍可能部分成功、部分阻塞 - 重试时建议搭配
std::chrono::steady_clock做指数退避，避免活锁；最多试 3–5 次，之后应记录告警或降级处理 - 常见误用：在持有
std::shared_lock期间调用std::try_lock写锁——读锁未释放，写锁等不到，新读请求又在排队，直接堵死
调试阶段必须开的检测开关
生产环境靠设计预防，调试阶段靠工具暴露隐患。ThreadSanitizer（TSan）是目前最实用的运行时辅助工具。
- 编译加
-fsanitize=thread -O0（开启 TSan 必须关优化，否则漏报） - 它不防止死锁，但会在复现路径中报告
potential deadlock due to inconsistent lock ordering - 注意：TSan 对
std::shared_mutex的混合读写场景敏感度较低，这种情况下要靠人工审查锁升级路径 - 线上禁用 TSan——它有 5–10 倍性能开销，且会干扰 futex 调度行为
最容易被忽略的点是：std::scoped_lock 只解决“同一批锁”的顺序问题，它不管锁的粒度是否合理、不管函数内是否调用了可能间接持锁的第三方代码（比如日志库、序列化函数）、也不管跨线程对象生命周期——这些地方才是真实项目里死锁反复冒头的温床。
