可重入指同一线程可多次调用未完成函数而不破坏状态;线程安全指多线程并发访问共享资源时不出现数据竞争。二者不等价:可重入关注单线程重入能力,线程安全关注多线程并发保护。
可重入 ≠ 线程安全,但二者常被混用。可重入指:**同一函数/方法在未执行完时,能被同一线程再次调用且不破坏内部状态**;典型场景是信号处理、递归调用或回调嵌套。lock 会阻塞同一线程再次进入(除非用 RecursiveLock 或 Monitor.TryEnter 配超时),所以普通 lock 块默认不可重入。
线程安全则关注**多线程并发访问共享资源时不出现数据竞争或状态不一致**。它不要求可重入——比如一个只读的静态缓存可能线程安全但无需支持重入。
在 C# 中,真正同时满足“可重入 + 线程安全”的常见做法是:用 Monitor 手动控制重入计数,或改用 AsyncLocal / 不可变对象 / 纯函数式设计来规避共享状态。
Monitor 实现可重入锁(ReentrantLock)C# 的 lock 语句底层就是 Monitor.Enter/Exit,但它不暴露重入计数。要自己实现可重入行为,必须用 Monitor.TryEnter(obj, timeout) 并手动维护线程 ID 与进入次数映射。
注意:Monitor 本身是可重入的(.NET 运行时保证同一线程多次 Enter 不死锁),但你得确保每次 Exit 次数匹配,否则其他线程永远等不到释放。
Monitor.Enter 和 Monitor.Exit 必须成对出现在同一个线程中;异常时需 try/finally 保障 Exit
Monitor.Exit,会抛 SynchronizationLockException
public class ReentrantLock
{
private readonly object _syncRoot = new object();
private Thread? _owner;
private int _entryCount;
public void Enter()
{
var current = Thread.CurrentThread;
lock (_syncRoot)
{
if (_owner == current)
{
_entryCount++;
return;
}
Monitor.Enter(_syncRoot); // 等待获取锁
_owner = current;
_entryCount = 1;
}
}
public void Exit()
{
lock (_syncRoot)
{
if (Thread.CurrentThread != _owner)
throw new InvalidOperationException("Exit called from non-owner thread");
if (--_entryCount == 0)
{
_owner = null;
Monitor.Exit(_syncRoot);
}
}
}}
更轻量、更现代的替代方案:避免锁,用 AsyncLocal 或不可变状态
如果你的“可重入”需求本质是想让递归调用或异步嵌套保持上下文隔离(比如日志追踪 ID、事务作用域),AsyncLocal 是比手写可重入锁更安全、更符合 .NET 设计哲学的选择。
它自动随 async/await 流动,且每个逻辑执行路径拥有独立副本,天然线程安全、天然可重入——因为根本不共享状态。
AsyncLocal 不适用于跨线程同步共享数据,只用于“逻辑上下文传播”ImmutableArray + Interlocked 更新引用,而非加锁private static readonly AsyncLocal_traceId = new AsyncLocal (); public void DoWork(string id) { _traceId.Value = id; // 当前逻辑流独享 NestedCall(); }
private void NestedCall() { Console.WriteLine($"Current trace: {_traceId.Value}"); // 自动继承,不污染其他分支 }
lock(this) 或 lock(typeof(T)) 当可重入锁用这些写法不仅不可重入,还极易引发死锁或意外锁竞争:
lock(this) 暴露了实例锁,外部代码也能锁它,导致协作失控lock(typeof(T)) 是全 AppDomain/Assembly 级别锁,多个类库可能无意中锁住同一 Type 对象Monitor.Enter(obj) 后没配对 Monitor.Exit(obj) —— 尤其在异常分支遗漏 finally,会导致永久挂起async 方法里用 lock:await 会切出线程,再回来时可能已不是原线程,Monit
or 不允许跨线程 Exit真正的难点不在“怎么写锁”,而在于判断“是否真的需要锁”。多数业务逻辑的可重入需求,其实源于状态管理混乱——把上下文塞进静态字段、单例属性,才被迫去解决线程安全问题。重构掉共享可变状态,往往比写一个完美的 ReentrantLock 更有效。