应直接使用标准库的std::recursive_mutex，它通过线程ID识别和嵌套计数实现安全重入，不可复制移动，且比手写更可靠高效。
std::recursive_mutex 是标准解，别自己手写
直接用 std::recursive_mutex，C++11 起就已标准化，无需自己实现。自己手写递归锁极易出错：漏计数、线程ID比较不严谨、析构异常导致死锁等问题频发。标准库实现经过大量测试和平台适配，且通常能映射到底层 OS 原语（如 Windows 的 CRITICAL_SECTION 或 pthread_mutex_t 的递归属性），性能有保障。
- 头文件只需
#include <mutex></mutex> - 声明方式：
std::recursive_mutex mtx; - 使用方式与
std::mutex完全一致：mtx.lock()/mtx.unlock()/std::lock_guard<:recursive_mutex>(mtx)</:recursive_mutex> - 注意：
std::mutex不支持递归加锁，重复 lock 会触发未定义行为（常见表现是程序 abort 或死锁）
为什么 std::recursive_mutex 能重入
它内部维护两个关键状态：持有线程 ID 和嵌套深度计数。每次同一线程调用 lock()，计数加一；每次 unlock()，计数减一；仅当计数归零时才真正释放底层互斥体。这个机制决定了它必须能识别当前线程——因此不能跨线程拷贝或转移，std::recursive_mutex 是不可复制、不可移动的类型。
- 若在非持有线程上调用
unlock()，行为未定义（不是抛异常，而是可能 crash 或静默失败） - 嵌套层级无硬性上限，但过深嵌套可能暴露栈溢出风险，尤其在递归函数中混用锁时需警惕
- 相比
std::mutex，std::recursive_mutex有轻微运行时开销（线程ID检查 + 计数操作），高频短临界区建议优先用普通 mutex
pthread 层面如何启用递归锁（Linux/macOS）
如果你在写跨平台基础库或需要细粒度控制，可能绕过 C++ 标准库直用 pthread。此时需显式设置 mutex 属性：
pthread_mutex_t mtx; pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); pthread_mutex_init(&mtx, &attr); pthread_mutexattr_destroy(&attr);
- 不设
PTHREAD_MUTEX_RECURSIVE时，默认是快速锁（PTHREAD_MUTEX_NORMAL），重复 lock 会导致死锁 -
PTHREAD_MUTEX_ERRORCHECK类型可检测重复 lock 并返回EDEADLK，但不提供重入能力 - 务必配对调用
pthread_mutex_destroy()，否则资源泄漏；C++ 的std::recursive_mutex在析构时自动清理
容易被忽略的 RAII 陷阱
用 std::lock_guard 或 std::unique_lock 管理 std::recursive_mutex 是安全的，但要注意作用域嵌套时的解锁顺序。例如函数内多次构造 std::lock_guard，每个都会增加计数，也各自减少计数——这本身没问题，但若中间抛异常，依赖栈展开自动析构，就必须确保所有 guard 对象都声明在 try 块内或具备强异常安全保证。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
std::lock_guard<:recursive_mutex> g1(mtx); do_something(); std::lock_guard<:recursive_mutex> g2(mtx);</:recursive_mutex></:recursive_mutex>—— 如果do_something()抛异常，g2构造失败，g1仍会正常析构，逻辑上合理，但易让人误以为“锁没释放” - 更清晰的做法是把锁的作用域显式限定在最小必要块内：
{ std::lock_guard<:recursive_mutex> g(mtx); /* work */ }</:recursive_mutex> - 不要试图用
std::recursive_mutex解决设计问题：比如本该用读写锁却靠递归锁硬撑，或因循环依赖被迫多层加锁——这类信号往往说明模块边界或调用链需要重构
递归锁不是银弹，它的存在是为了简化特定场景（如递归算法、回调重入、遗留接口兼容），而不是鼓励任意嵌套加锁。真正难的从来不是“怎么加锁”，而是“哪些路径会持有哪些锁”以及“锁的粒度是否匹配数据访问模式”。
