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