std::recursive_mutex通过线程id和计数器支持同线程多次lock，仅计数归零时才释放锁；而std::mutex不支持嵌套加锁，同线程重复lock会无限等待导致死锁。
std::recursive_mutex 能解决同一线程内多次加锁导致的死锁，但必须严格匹配 lock/unlock 次数，否则其他线程永远拿不到锁。
为什么普通 mutex 在嵌套调用里会死锁
当一个已持有 std::mutex 的线程再次调用 lock()，它会无限等待自己释放锁——这根本不可能发生。典型场景是递归函数、回调入口、或公共接口内部又调用了另一个需保护共享数据的私有方法。比如：
void process_node(Node* n) {
mtx.lock(); // 第一次 lock
if (n->left) process_node(n->left); // 再次进入，对同一 mtx 调用 lock → 死锁
mtx.unlock();
}
这种结构在树遍历、事件分发、状态机跳转中很常见。而 std::recursive_mutex 内部维护线程 ID 和计数器，允许同一线程重复 lock()，只在计数归零时才真正释放。
std::recursive_mutex 的 lock/unlock 必须严格配对
它不像 std::lock_guard 那样自动管理生命周期，裸写 lock()/unlock() 极易出错。常见错误包括：
- 异常路径中漏掉
unlock()，导致锁永久被占用 - 递归深度不固定时，手动计数 unlock 次数容易错位
- 混用
std::lock_guard<:recursive_mutex></:recursive_mutex>—— 它只做一次构造 lock + 析构 unlock，无法应对多层嵌套
正确做法是改用 std::unique_lock<:recursive_mutex></:recursive_mutex>，它支持延迟锁定、中途 unlock()、再 lock()，且能配合 RAII 管理异常安全：
void increment() {
std::unique_lock<:recursive_mutex> lk(mtx_);
++value_;
if (value_ <h3>性能和重构权衡：递归锁不是银弹</h3>
<p><code>std::recursive_mutex</code> 比 <code>std::mutex</code> 多一次线程 ID 比较和计数器增减，实测开销高 10%–20%。更关键的是，它掩盖了设计问题：</p>
<ul>
<li>频繁嵌套加锁往往说明职责没拆清，比如“加锁 + 执行”混在一个函数里</li>
<li>更好的解法是把临界区逻辑抽成无锁的私有函数，由顶层加锁后统一调用</li>
<li>若回调链路不可控（如插件系统），才真正需要递归锁；否则优先重构</li>
</ul>
<p>例如将 <code>update_path()</code> 拆为 <code>update_path_locked()</code>（不加锁）和 public <code>update_path()</code>（加锁后调用前者），就能完全避开递归锁。</p>
<h3>跨平台注意：Windows CRITICAL_SECTION 行为类似但不等价</h3>
<p>Windows 的 <code>CRITICAL_SECTION</code> 默认支持递归进入，行为上接近 <code>std::recursive_mutex</code>，但 C++ 标准不保证其可移植。如果代码要跨平台：</p>
<ul>
<li>别依赖 <code>CRITICAL_SECTION</code> 的递归特性来写逻辑</li>
<li>统一用 <code>std::recursive_mutex</code>，并确保所有 <code>lock()</code> 都有对应 <code>unlock()</code>
</li>
<li>注意 Windows 下 <code>CRITICAL_SECTION</code> 初始化需调用 <code>InitializeCriticalSection()</code>，而 <code>std::recursive_mutex</code> 构造即就绪</li>
</ul>
<p>最容易被忽略的点是：递归锁只解决“同一线程重复加锁”的死锁，但绝不解决“多线程间加锁顺序不一致”导致的死锁。后者仍需靠锁排序、死锁检测或无锁设计来规避。</p></:recursive_mutex>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
