recursive_mutex 解决同一线程多次加锁导致的死锁问题，通过维护线程id和计数器实现可重入性；它不解决跨线程竞争或漏锁问题，性能略低于mutex，仅适用于必要递归场景。
recursive_mutex 能解决什么问题？
当你在同一个线程里，多次进入同一把锁保护的临界区（比如递归调用、嵌套函数调用、或回调中又触发原函数），std::mutex 会直接死锁——因为它是不可重入的。而 std::recursive_mutex 就是为此设计的：它允许同一线程反复加锁，内部维护一个计数器，只有解锁次数匹配加锁次数时，锁才真正释放。
怎么正确声明和使用 recursive_mutex？
用法和普通 mutex 几乎一样，但语义不同。别把它当成“更安全的 mutex”，它只是为特定场景存在。
- 声明：
std::recursive_mutex mtx;（不能用std::mutex替代） - 加锁：
mtx.lock()或std::lock_guard<:recursive_mutex> guard(mtx);</:recursive_mutex> - 解锁：
mtx.unlock()（手动配对）或依赖 RAII 自动释放 - 注意：
std::unique_lock<:recursive_mutex></:recursive_mutex>同样支持，且能延迟加锁、转移所有权
递归调用中不加锁会怎样？加错锁呢？
典型错误是：以为用了 recursive_mutex 就万事大吉，结果在递归路径上漏锁，或跨线程误用。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 漏锁：比如只在入口加锁，但递归分支里没锁，导致数据竞争 ——
recursive_mutex不会帮你自动覆盖所有路径 - 跨线程加同一把锁：它只保证同一线程可重入，**不同线程仍会阻塞等待**，这点和普通 mutex 完全一致
- 忘记解锁（尤其手动调用
unlock()）：会导致后续所有同一线程的lock()都卡住，因为计数器永远不归零 - 性能开销略高：内部要维护 owner thread ID 和计数，比
std::mutex稍慢，非必要别滥用
一个真实递归场景示例
比如树的深度优先遍历，每个节点处理逻辑可能触发子节点回调，而整个遍历必须线程安全：
class Tree {
std::recursive_mutex mtx;
void traverse(Node* node) {
std::lock_guard<:recursive_mutex> guard(mtx);
if (!node) return;
process(node);
// 可能触发回调，回调里又调用 traverse —— 同一线程，合法
for (auto child : node->children) {
traverse(child);
}
}
};</:recursive_mutex>
这里关键是：所有递归入口都走同一把 mtx，且全程用 RAII，避免手动 unlock 失误。如果换成 std::mutex，第二次 lock() 就会永久阻塞。
真正容易被忽略的是：recursive_mutex 解决不了设计问题。如果递归本身可以扁平化、或用栈模拟、或改用无锁结构，那比依赖重入锁更健壮。它只是兜底手段，不是架构捷径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
