std::mutex不支持同一线程重复加锁，会导致单线程阻塞；需改用std::recursive_mutex解决重入问题，但根本解法是重构接口、明确锁职责与契约。
std::mutex 不支持同一线程重复加锁
直接用 std::mutex 在同一线程中嵌套调用 lock()（或通过 std::lock_guard 构造）会导致未定义行为，常见表现是程序阻塞在第二次加锁处，看起来像死锁——但其实不是循环等待，而是单线程自陷。
典型场景：工具函数被多个入口调用，其中某个入口已持锁，再调用另一个也尝试加同一把锁的函数。例如：
void update_sensor() {
std::lock_guard<std::mutex> lk(sensor_mtx);
process_raw_data();
trigger_decision(); // 内部又写了 std::lock_guard<std::mutex> lk(sensor_mtx);
}
这种写法在绝大多数实现上会卡住，因为 std::mutex 是非递归的。
- 别指望它“自动识别同线程”——它根本不会识别
- 不能靠
try_lock()来绕过：即使返回false，你也得处理“已持有”和“未持有”两种状态，逻辑爆炸 - 日志里看不到跨线程等待痕迹，
ps显示 CPU 为 0，gdb 查栈会发现线程停在pthread_mutex_lock内部
std::recursive_mutex 是唯一合法解法
如果你确实需要同一线程多次进入同一临界区（比如递归算法、分层调用、回调重入），必须换用 std::recursive_mutex，而不是硬扛或加标志位模拟。
立即学习“C++免费学习笔记（深入）”；
它和 std::mutex 接口一致，但内部维护持有计数；每次 lock() 增计数，每次 unlock() 减计数，仅当计数归零才真正释放锁。
- 构造
std::lock_guard<:recursive_mutex></:recursive_mutex>完全合法，且 RAII 行为不变 - 性能开销略高（需原子计数 + 线程 ID 检查），但比逻辑错乱或手动管理安全得多
- 注意：它不解决多锁间的顺序问题，只解决单锁重入——别误以为用了它就不用管锁顺序了
嵌套调用时锁粒度混乱才是真隐患
很多人改用 std::recursive_mutex 后松一口气，却忽略了更危险的问题：函数接口没暴露锁依赖，调用方无法判断是否已持锁，导致锁范围不可控、临界区膨胀、性能下降甚至新死锁。
比如一个 save_to_db() 函数内部加了锁，而它的调用者 batch_process() 也加了同一把锁——这不是重入问题，是设计缺陷。
- 优先重构：把加锁逻辑提到最外层，内层函数改为无锁纯逻辑（如
save_to_db_unlocked()） - 若必须保留封装，明确命名并文档化“该函数要求调用方已持锁”，或用类型系统隔离（如传入
std::unique_lock<std::mutex>&参数） - 禁止在头文件里隐藏锁行为；头文件声明应反映真实契约
std::lock 配合多个 std::mutex 可防交叉死锁
嵌套本身不必然导致死锁，但多个锁 + 不统一顺序就会。比如 A 函数按 mtx_a→mtx_b 加锁，B 函数按 mtx_b→mtx_a 加，哪怕都用 std::lock_guard 也挡不住死锁。
std::lock 能原子化地同时锁定多个互斥量，内部使用避免死锁的试探/回退策略（如按地址排序），确保不会出现“只锁了一个就阻塞”的中间态。
- 正确用法：
std::lock(mtx_a, mtx_b); std::lock_guard<:mutex> lk1(mtx_a, std::defer_lock); std::lock_guard<:mutex> lk2(mtx_b, std::defer_lock);</:mutex></:mutex> - 千万别写成先
lk1(mtx_a)再std::lock(mtx_b, mtx_c)——这又回到分步加锁的老路 - 搭配
std::adopt_lock才能和std::lock协同：构造std::lock_guard时告诉它“锁已由我手动拿好”
