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

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

什么是 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 线程重入等场景下静默崩溃或死锁。

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

极少数场景下，你可能想禁止同一线程重复进入（比如调试竞态、强制扁平化调用栈），此时不能依赖 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 一样安全，然后随意混用不同同步原语。
					技术教程SEO





 上一篇 : Ruby on Rails怎么渲染XML响应 to_xml方法 




 下一篇 : 全电发票怎么查询真伪 数电票查验及下载操作流程【详解】