std::recursive_mutex是否会引发死锁？替换std::mutex后有无其他隐患？

1. 跨线程循环等待仍会引发死锁 #

std::recursive_mutex只解决同一线程内重复加锁的死锁问题，但经典的跨线程循环等待场景依然会导致死锁。比如：

• 线程A先锁定recursive_mutex A，再尝试锁定recursive_mutex B
• 线程B先锁定recursive_mutex B，再尝试锁定recursive_mutex A
  这种情况下两个线程会互相等待对方释放锁，最终触发死锁。

2. 容易掩盖代码设计缺陷 #

过度依赖递归锁往往是代码逻辑不合理的信号：

• 它会隐藏函数调用链中的嵌套加锁问题，比如函数A加锁后调用了同样会加锁的函数B，开发者可能意识不到这种重复加锁的存在，导致后续维护时逻辑复杂度陡增。
• 容易让开发者放松对锁粒度的控制，出现锁持有时间过长、锁范围过大的情况，反而会放大并发性能损耗，比递归锁本身的性能影响更严重。

3. 解锁次数必须严格匹配 #

std::recursive_mutex要求解锁次数和加锁次数完全一致：

• 解锁次数少了，锁不会被释放，其他线程永远拿不到锁；
• 解锁次数多了，会触发未定义行为（比如程序直接崩溃）。
  这种要求在复杂分支或异常场景下很容易出错，比如某个分支提前return但没处理解锁计数，就会留下隐患。

4. 性能损耗不止“略低” #

除了递归锁本身维护加锁计数的额外开销，它还可能间接导致更多上下文切换：因为锁持有时间可能被不合理的嵌套逻辑拉长，其他线程等待锁的时间更久，整体并发效率会进一步下降。

内容的提问来源于stack exchange，提问作者kevin h