17370845950

Monitor 是 C# 中最常用、最接近 Java ReentrantLock 语义的可重入锁机制，基于 .NET 运行时内置同步原语实现，支持同一线程多次进入并自动维护计数，lock(obj) 是其语法糖；而 System.Threading.Lock（.NET 5+）不可重入，适用于短临界区与高性能场景。

有，Monitor 是 C# 中最常用、也最接近 Java ReentrantLock 语义的可重入锁机制，但它不是类而是语言级构造；.NET 5+ 还提供了更显式的 System.Threading.Lock（仅限 .NET 5+），但默认不可重入。

Monitor.Enter / Monitor.Exit 是 C# 的可重入锁核心

Monitor 是 .NET 运行时内置的同步原语，支持同一线程多次进入（即重入），且自动维护计数。它不依赖 IDisposable，但推荐配合 try/finally 或 using（C# 8+ 的 lock 语法糖）使用。

• lock(obj) 本质就是 Monitor.Enter(obj) + try/finally + Monitor.Exit(obj)
• 同一对象上，同一线程重复 lock 不会死锁，计数器递增；对应次数的 Exit 后才真正释放锁
• 注意：Monitor 锁的是引用对象的“同步块索引”，不是对象内容或类型；多个线程对同一实例 lock 才互斥
• 不要用 string、装箱值类型或常量作为锁对象——它们可能被池化或共享，导致意外锁竞争

Monitor.TryEnter 可实现带超时的可重入尝试

当需要避免无限等待时，Monitor.TryEnter 比直接 lock 更灵活，且仍保持可重入特性。

object syncRoot = new object();
if (Monitor.TryEnter(syncRoot, TimeSpan.FromMilliseconds(100)))
{
    try
    {
        // 临界区
        if (Monitor.TryEnter(syncRoot, 0)) // 同一线程再次进入：成功，计数+1
        {
            try
            {
                // 嵌套临界区
            }
            finally
            {
                Monitor.Exit(syncRoot);
            }
        }
    }
    finally
    {
        Monitor.Exit(syncRoot);
    }
}
else
{
    // 获取锁失败
}

• TryEnter(obj, timeout) 返回 bool，超时前未获取到则返回 false
• 即使在 TryEnter 成功后，后续同一线程的 TryEnter（无论 timeout=0 或 >0）仍会成功并增加重入计数
• 必须严格配对 Exit，否则锁不会完全释放，其他线程将永久阻塞

System.Threading.Lock（.NET 5+）不是可重入的

System.Threading.Lock 是为高性能、低分配场景设计的结构体锁，但它明确不可重入：同一线程重复 Lock.Enter 会抛出 InvalidOperationException。

• 适用场景：短临界区、已确保无嵌套调用、追求极致性能（避免堆分配和 Monitor 内部哈希查找）
• 若业务逻辑天然存在递归或间接重入（比如 A 调 B，B 又 lock 同一资源），用它会直接崩溃
• 没有等价于 ReentrantLock.isHeldByCurrentThread() 的检查方法；也不支持条件变量（Condition）

自定义 ReentrantLock 类需谨慎权衡

虽然可以用 Monitor 封装一个类似 Java ReentrantLock 的 API（如 lock()/unlock()、isHeldByCurrentThread()），但实际极少必要。

• .NET 生态中绝大多数并发控制靠 lock、Monitor、AsyncLock（如 Microsoft.Extensions.DependencyInjection 中的异步锁）或无锁结构（ConcurrentDictionary 等）解决
• 手动维护持有线程 ID 和计数容易出错，尤其在异步上下文（async/await）中，线程切换会导致 Thread.CurrentThread.ManagedThreadId 不一致
• 若真需类似 Java 的显式锁 API（比如

  

  公平性、中断响应、条件队列），应优先评估是否能用 System.Threading.SemaphoreSlim（支持 async、可取消）替代

真正容易被忽略的是：可重入 ≠ 安全。哪怕 Monitor 允许重入，如果锁粒度太粗、嵌套过深或跨 await 边界持有，依然会导致死锁、响应延迟或上下文丢失。写锁逻辑时，先想清楚“谁要等谁”，再决定用哪一层抽象。