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一样安全，然后随意混用不同同步原语。
