c# C# 中的可重入锁（Reentrant Lock）和递归 lock

2026-01-17

c# C# 中的可重入锁（Reentrant Lock）和递归 lock

C# 中的 lock 语句是可重入的，基于 Monitor 实现，同一线程可多次进入并自动维护计数器；而 Mutex、SemaphoreSlim、SpinLock 等默认不可重入，混用易致死锁或异常。

c# c# 中的可重入锁（reentrant lock）和递归 lock

什么是 C# 中的可重入锁（Reentrant Lock）

在 C# 中，lock 语句本身就是可重入的（reentrant），也就是常说的“递归 lock”——同一个线程可以多次获取它已持有的同一把锁，而不会死锁。这和 Java 的 synchronized 类似，但不同于 pthread 或 .NET 中某些手动实现的非可重入原语（如 Mutex）。

关键点在于：lock(obj) 底层调用的是 Monitor.Enter，而 Monitor 是可重入的：它会记录持有锁的线程 ID 和进入次数，只有当该线程调用对应次数的 Monitor.Exit（或通过 lock 自动释放）后，锁才真正释放。

为什么 lock(obj) 不会导致同线程死锁

这是 Monitor 的设计行为，不是“例外”或“bug”，而是有意为之的线程安全保障机制。常见误解是以为“锁住了就不能再进”，其实只要当前线程是持有者，Monitor.Enter 就直接成功并递增计数。

lock(obj) 在同一线程内嵌套调用时，不会阻塞，也不会抛异常
每次进入都会使内部计数器 +1；每次退出（离开 lock 块）-1
只有计数器归零时，其他线程才可能抢到该锁
若在 lock 块中抛出未捕获异常，Monitor.Exit 仍会由 finally 保证执行（这是 lock 安全的关键）

哪些锁类型不是可重入的？容易踩坑的地方

不是所有 .NET 同步原语都支持可重入。混淆它们是实际开发中最常见的线程问题源头之一。

Mutex：默认不可重入。同一线程重复 WaitOne() 会无限等待（除非构造时传 true 启用递归模式，即 new Mutex(false, name) 中的 false 表示非递归，true 才是递归——注意参数顺序易错）
SemaphoreSlim：不可重入。即使同一线程多次 WaitAsync()，也会按信号量计数扣减，超限就挂起
SpinLock：不可重入。同一线程重复 Enter() 会触发 InvalidOperationException：“Recursive entry is not allowed”
手写基于 Interlocked 的轻量锁：默认不可重入，需显式记录线程 ID 和计数才能模拟

所以，如果你替换 lock 为其他原语来“优化性能”，却没意识到可重入性丢失，很可能在递归调用、事件回调、WPF/WinForms 的 UI 线程重入等场景下静默崩溃或死锁。

标小兔AI写标书

一款专业的标书AI代写平台，提供专业AI标书代写服务，安全、稳定、速度快，可满足各类招投标需求，标小兔，写标书，快如兔。

下载

需要显式控制可重入行为时怎么办

极少数场景下，你可能想禁止同一线程重复进入（比如调试竞态、强制扁平化调用栈），此时不能依赖 lock，而应主动检测：

private readonly object _lockObj = new();
private readonly ThreadLocal _isInLock = new(() => false);
public void CriticalMethod()
{
if (_isInLock.Value)
throw new InvalidOperationException("Reentrant call not allowed");
_isInLock.Value = true;
try
{
    lock (_lockObj)
    {
        // 实际逻辑
    }
}
finally
{
    _isInLock.Value = false;
}
}
注意：ThreadLocal 开销略高，仅用于诊断或强约束场景；生产代码中更推荐靠设计规避递归（如拆分方法、用状态机），而不是 runtime 拦截。
可重入性本身不是缺陷，而是 lock 可靠性的基石；真正危险的是误以为所有锁都像 lock 一样安全，然后随意混用不同同步原语。
https://www.php.cn/faq/1992457.html