关键区别是可重入性：recursive_timed_mutex允许同一线程多次lock()而不死锁，timed_mutex重复lock()为未定义行为；前者需维护计数和线程ID，性能更低、内存更大。
recursive_timed_mutex 和普通 timed_mutex 有什么关键区别
核心区别在于「可重入性」：recursive_timed_mutex 允许同一线程多次调用 lock() 或 try_lock_for()，而不会死锁；普通 timed_mutex 在同一线程重复 lock() 是未定义行为（通常 crash 或 hang）。但代价是内部需维护持有计数和线程 ID，性能略低、内存占用稍大。
典型误用场景：把 recursive_timed_mutex 当成「更安全的 timed_mutex」无脑替换——其实只要没递归加锁需求，就该用更轻量的 timed_mutex。
什么时候必须用 recursive_timed_mutex
仅当存在「同一线程内可能多次进入同一临界区」且又需要超时控制时才需要它。常见于：
- 递归调用的算法封装（比如树遍历中每个节点操作都需加锁）
- 虚函数多态调用链中，基类和派生类方法各自尝试加同一把锁
- 回调函数被同步触发，且回调里又调用了持有该锁的外层方法
注意：recursive_timed_mutex 不解决「跨线程死锁」，也不替代设计层面的锁粒度优化。如果发现频繁依赖它，大概率是接口设计或调用路径需要重构。
立即学习“C++免费学习笔记（深入）”；
lock() / try_lock_for() / unlock() 的配对陷阱
recursive_timed_mutex 要求 unlock() 次数严格等于 lock() 或成功 try_lock_for() 的次数，否则行为未定义（常见表现是后续 lock() 永远阻塞，或 unlock() 崩溃）。
容易踩的坑：
- 异常中途跳出，导致
unlock()没执行（必须用 RAII，如std::unique_lock<recursive_timed_mutex>） - 混用
lock()和try_lock_for()：一次lock()+ 一次try_lock_for()成功，需调用两次unlock() - 在
try_lock_for()返回false后误调unlock()（未持有锁时调用unlock()是未定义行为）
正确写法示例：
std::recursive_timed_mutex mtx;
std::unique_lock<std::recursive_timed_mutex> lock(mtx, std::chrono::milliseconds(100));
if (!lock.owns_lock()) {
// 超时，不执行 unlock()
return false;
}
// 自动在作用域结束时 unlock()，且支持重入
超时精度与系统调度的影响
try_lock_for() 的超时不是硬实时保证。实际等待时间可能略长于指定值，尤其在高负载或线程优先级低的系统上。Windows 下基于 WaitForSingleObject，Linux 下通常基于 futex + clock_nanosleep，都有最小调度粒度限制（常为 1–15ms）。
因此：
- 不要用它实现微秒级精确等待
- 避免设置过短超时（如
1us），可能立即返回false，失去意义 - 若需轮询+超时组合逻辑，优先考虑
try_lock_until()配合steady_clock，比反复try_lock_for()更可靠
真正难处理的从来不是语法，而是递归加锁场景下「谁该负责释放」「异常路径是否全覆盖」「超时后业务状态如何回滚」——这些没法靠 mutex 类型自动解决。
