std::recursive_mutex 是 C++ 标准库中专门用于处理递归加锁场景的互斥量，它定义在 <mutex> 头文件中。与普通互斥锁不同，递归互斥锁允许同一个线程在已经持有锁的情况下再次执行加锁操作，而不会因为锁已经被自身占用而陷入死锁。它的核心用途是在递归函数、嵌套调用以及无法预知重复加锁次数的复杂控制流中保护共享数据。理解这一类型的锁，对编写可靠的并发程序十分重要。
std::recursive_mutex 的核心作用与递归加锁机制
普通互斥锁 std::mutex 在同一个线程中只能被成功加锁一次。如果某个线程在已经持锁的情况下再次调用 lock()，按照标准库的行为，通常会直接造成死锁，或者由实现返回错误。这在递归函数场景中几乎必然出现：递归函数的每一层都会尝试获取同一个锁，第一层已经持有锁，第二层再次加锁时普通互斥锁无法识别这是同一个线程，于是线程会阻塞在自身持有的锁上，程序无法继续执行。
递归互斥锁在设计上解决了这个问题。它在内部不仅记录锁是否被占用，还会记录当前持锁线程的标识以及该线程的重复加锁次数。当 lock() 被调用时，如果锁尚未被占用，则当前线程获得锁并记录一次加锁；如果锁已经被当前线程占用，则不会阻塞，而是将内部的加锁计数加一。对应地，每次调用 unlock() 时，内部计数减一，只有当计数归零时才真正释放锁的所有权，允许其他线程竞争获取。
这种机制使得递归函数可以安全地写成每一层独立获取锁、独立释放锁的形式。例如一个处理树形结构的递归函数，在每一层访问共享结果集合之前都调用 lock()，在返回之前调用 unlock()，递归调用自然形成多次加锁，程序仍然能够正确运行，不需要在递归边界之外额外设计复杂的锁状态判断。
使用规则与注意事项
使用 std::recursive_mutex 时，最重要的规则是加锁次数与解锁次数必须严格相等。递归互斥锁内部维护一个计数，同一个线程每调用一次 lock() 或 try_lock() 成功，计数就增加一；每调用一次 unlock()，计数就减少一。只有计数重新回到零时，锁才会被真正释放。如果某个线程加了三次锁却只释放了两次，那么其他线程将永远无法获取该锁，程序可能出现资源无法继续推进的问题。
另一个需要明确的事实是，递归互斥锁并不会破坏线程之间的互斥性。允许同一线程重复加锁，并不代表多个线程可以同时持有锁。当一个线程已经持有递归互斥锁时，其他线程如果尝试加锁，仍然会进入阻塞状态，直到持锁线程将所有加锁计数全部释放。因此，递归互斥锁仍然能够保证临界区在同一时刻只被一个线程访问，只是它放宽了对“同一线程重复进入临界区”的限制。
- 同一线程每次成功的
lock()必须对应一次unlock()，二者次数必须匹配。 - 不同线程之间仍然互斥，递归只针对同一个线程的重复获取。
- 避免在没有递归或嵌套需求的地方随意使用递归互斥锁，因为维护线程标识和计数会带来额外开销。
在开发中还需要警惕一个隐蔽的问题：如果一个线程加锁后抛出异常，而解锁逻辑没有通过 RAII 或异常安全的方式保证执行，就可能导致计数没有归零，锁被永久占用。因此推荐使用 std::unique_lock 或 std::lock_guard 配合递归互斥锁，让析构函数自动完成解锁。
递归加锁的代码示例与输出分析
下面通过一个递归函数访问共享计数器的例子演示 std::recursive_mutex 的实际用法。函数 recursive_func 接收一个深度参数，每次进入函数都会先对同一个递归互斥锁加锁，然后修改共享计数器，并在深度大于零时继续递归调用自身。由于使用的是递归互斥锁，同一线程再次加锁不会发生死锁。
#include <iostream>
#include <mutex>
#include <thread>
std::recursive_mutex rec_mtx;
int shared_counter = 0;
void recursive_func(int depth) {
// 每次进入函数都尝试获取同一个递归互斥锁
rec_mtx.lock();
std::cout << "thread " << std::this_thread::get_id()
<< " enter, depth is " << depth << std::endl;
shared_counter++;
if (depth > 0) {
// 递归调用，同一线程再次加锁，不会死锁
recursive_func(depth - 1);
}
std::cout << "thread " << std::this_thread::get_id()
<< " leave, depth is " << depth << std::endl;
// 本次加锁对应的解锁操作
rec_mtx.unlock();
}
int main() {
// 两个线程各自执行深度为 2 的递归调用
std::thread t1(recursive_func, 2);
std::thread t2(recursive_func, 2);
t1.join();
t2.join();
std::cout << "final counter: " << shared_counter << std::endl;
return 0;
}
在这个例子中，每个线程会调用 recursive_func 三次，分别是深度 2、深度 1 和深度 0，因此每个线程会执行三次加锁和三次解锁操作。共享计数器在两个线程都结束后从 0 增加到 4，说明递归互斥锁在保证同一线程重复加锁时不阻塞的同时，仍然能够正确协调两个线程对共享计数器的累加操作。
在实际开发中，手动调用 lock() 和 手动调用 `lock()` 和 `unlock()` 的问题在于一旦代码路径变得复杂，就容易出现遗漏解锁或异常路径未解锁的情况，进而导致死锁或锁泄漏。为了降低这类风险，C++ 标准库提供了基于 RAII 的锁封装，例如 `std::lock_guard` 和 `std::unique_lock`。它们会在构造时自动加锁，在析构时自动解锁，从而保证无论函数以何种方式返回，锁都能被正确释放。对于递归互斥锁，同样可以使用这些封装来简化代码。
下面的示例展示了如何配合 `std::lock_guard` 使用 `std::recursive_mutex`。在递归函数内部，每次进入函数都会创建一个新的 `lock_guard` 对象，它会在当前作用域结束时自动调用 `unlock()`，即使递归深度增加，也不会影响每一层锁的独立管理。
<code>#include <iostream>
#include <mutex>
#include <thread>
std::recursive_mutex rec_mtx;
int shared_counter = 0;
void recursive_func(int depth) {
// 使用 RAII 封装，离开作用域时自动解锁
std::lock_guard<std::recursive_mutex> lock(rec_mtx);
shared_counter++;
std::cout << "thread " << std::this_thread::get_id()
<< " enter, depth is " << depth << std::endl;
if (depth > 0) {
recursive_func(depth - 1);
}
std::cout << "thread " << std::this_thread::get_id()
<< " leave, depth is " << depth << std::endl;
}
int main() {
std::thread t1(recursive_func, 2);
std::thread t2(recursive_func, 2);
t1.join();
t2.join();
std::cout << "final counter: " << shared_counter << std::endl;
return 0;
}
</code>
与手动调用相比，这段代码更加简洁，也不需要显式关心每一层的 `unlock()` 是否与 `lock()` 一一对应。尤其是在递归深度较深或者中间存在提前返回的情况下，RAII 封装能够显著降低维护成本。
不过，`std::recursive_mutex` 并不是解决并发问题的万能钥匙。它虽然允许同一线程重复加锁，但也有一些明显的使用限制和注意事项。
其一，解锁次数必须与加锁次数完全匹配。即使使用 `lock_guard` 自动管理，也要保证逻辑上每一次加锁都有对应的一次解锁。递归锁内部维护了锁计数和所属线程信息，如果同一线程加锁的次数多于解锁次数，那么其他线程仍然无法获得锁；反之，如果解锁次数多于加锁次数，则会导致未定义行为。因此，使用递归锁时，最好将加锁与解锁控制在同一个函数或同一个逻辑层次中，避免跨函数、跨模块的不对称操作。
其二，避免跨线程解锁。`std::recursive_mutex` 只能由持有锁的线程进行解锁，如果线程 A 尝试解锁线程 B 持有的递归锁，行为是未定义的。这与普通 `std::mutex` 的要求一致，但在递归场景中更容易因为复杂的调用关系而被忽视。例如，不要把 `unlock()` 放到另一个线程的回调中去执行，也不要在异步任务中随意操作锁对象。
其三，递归锁有额外的性能开销。相比普通互斥锁，递归互斥锁需要维护锁计数和线程标识，并在每次加锁、解锁时进行额外检查。因此，在非必要场景下，应优先考虑普通 `std::mutex`。递归锁最适合的场景是：同一个线程可能在多个层次的函数调用中重复进入同一个临界区，并且这些函数之间难以通过重构完全避免重入。
其四，递归锁可能掩盖设计上的问题。如果代码中频繁需要递归加锁，往往说明锁的粒度较大，或者函数职责划分不够清晰。在一些情况下，更好的做法是拆分公共接口和私有实现，让公共接口负责加锁，私有实现假设锁已经持有，从而避免重复加锁。例如，一个类可以对外提供带锁的 `public` 方法，内部调用不带锁的 `private` 方法，这样既能保证线程安全，又能避免递归锁的使用。
<code>#include <iostream>
#include <mutex>
#include <thread>
class Counter {
public:
void increment() {
std::lock_guard<std::mutex> lock(mtx_);
increment_impl();
}
void increment_twice() {
std::lock_guard<std::mutex> lock(mtx_);
increment_impl();
increment_impl();
}
int value() const {
std::lock_guard<std::mutex> lock(mtx_);
return value_;
}
private:
void increment_impl() {
// 调用此函数时，锁已经由外层持有
++value_;
}
mutable std::mutex mtx_;
int value_ = 0;
};
int main() {
Counter counter;
std::thread t1([&counter] {
for (int i = 0; i < 1000; ++i) {
counter.increment_twice();
}
});
std::thread t2([&counter] {
for (int i = 0; i < 1000; ++i) {
counter.increment();
}
});
t1.join();
t2.join();
std::cout << "counter value: " << counter.value() << std::endl;
return 0;
}
</code>
在这个例子中，`increment()` 和 `increment_twice()` 都是公共接口，它们各自负责加锁，然后调用私有实现 `increment_impl()`。由于 `increment_impl()` 假定锁已经持有，因此它不会再次加锁。这种设计避免了在同一线程中重复进入临界区的问题，也就不需要 `std::recursive_mutex`。通过这种方式，锁的粒度可以保持得较小，代码结构也更加清晰。
当然，并非所有递归调用都能通过简单的接口拆分来解决。例如，当递归函数需要访问多个共享资源，或者递归逻辑本身与业务耦合较深时，引入 `std::recursive_mutex` 可能是更直接的选择。此时，应当明确文档化锁的使用规则，确保所有调用者理解“可以重入”这一特性，并严格维护加锁与解锁的对称性。
总结来说，`std::recursive_mutex` 是 C++ 标准库中一个有用的同步原语，它解决了同一线程重复加锁导致的死锁问题。但它也带来了额外的复杂性和开销，因此应在确有必要时使用。在大多数情况下，通过合理设计接口、缩小锁粒度、拆分带锁与不带锁的函数，可以避免使用递归锁，从而使并发代码更易于理解和维护。如果选择使用递归锁，建议配合 `std::lock_guard` 或 `std::unique_lock` 进行管理，并确保加锁与解锁严格匹配，避免跨线程操作。这样才能在保证线程安全的同时，保持代码的健壮性和可维护性。
std::recursive_mutexC++多线程互斥锁修改时间：2026-07-23 19:09:28