C#怎么使用lock线程锁_C# lock和Monitor线程安全教程【进阶】

C#如何正确使用lock线程锁？C# lock与Monitor线程安全进阶实战指南

首先明确一个核心原则：lock 关键字并非解决所有并发问题的万能钥匙。它只有在正确选择锁对象、精确划定临界区范围并规避常见误区时，才能有效保障线程安全。简而言之，在日常开发的大多数场景中，使用 lock 足以应对；但当你需要实现线程等待、条件通知、超时控制等高级同步机制时，就必须深入理解并切换到 Monitor 类提供的底层方法。

为什么不能使用 new object() 或 this 作为 lock 的锁对象？

初学者常犯的一个典型错误，是在方法内部临时创建 new object() 实例作为锁，或者为图方便直接使用 lock(this)。这两种做法本质上都无法实现线程同步，因为锁对象不具备唯一性，线程之间无法形成有效的互斥访问。

• new object()：每次调用都会生成全新的对象实例，不同线程锁定的是完全不同的对象，导致锁机制完全失效。
• this：指向当前实例的公开引用，外部代码也可能对其进行锁定，极易引发难以调试的死锁或意外的逻辑冲突。
• 字符串字面量：例如 lock(“myLock”)，由于 .NET 的字符串驻留机制，相同的字符串可能在应用程序域内被共享，从而带来意想不到的锁竞争范围扩大风险。

那么，正确的锁对象声明方式是什么？最佳实践是定义一个 private readonly object 类型的字段。对于需要跨实例同步的静态资源，强烈建议使用 static readonly（静态只读）修饰，以确保锁对象的生命周期与所要保护的共享资源完全匹配。参考以下示例：

private static readonly object _syncRoot = new object();
public void UpdateCounter() {
    lock (_syncRoot) {
        _counter++;
    }
}

lock 关键字与 Monitor.Enter/Exit 的等价关系及核心区别

从语法层面看，lock 非常简洁，但其本质是 C# 编译器提供的语法糖。编译器会将其转换为标准的 try-finally 代码块，并调用 Monitor.Enter(..., ref lockTaken) 方法。自 .NET Framework 4.0 起，这个 ref bool 参数变得至关重要——它专门用于处理 ThreadAbortException 等极端异步中断场景，确保锁在任何情况下都能被可靠释放，避免资源泄漏。

• lock 的优势：自动保障异常安全，编译器生成的代码确保锁最终被释放，开发者无法绕过此机制，降低了出错概率。
• Monitor.Enter 的灵活性：它允许你通过检查 lockTaken 标志来灵活控制流程，为实现“尝试获取锁”等高级模式提供了基础。
• 关键功能差异：如果你需要为锁的获取操作设置一个超时时间（例如最多等待100毫秒），那么必须使用 Monitor.TryEnter(obj, 100) 方法，这是 lock 关键字本身无法实现的功能。

以下代码演示了如何使用 Monitor.TryEnter 实现带超时控制的锁获取，其逻辑与 lock 等效，但赋予了程序更强的健壮性和控制力：

bool lockTaken = false;
try {
    if (Monitor.TryEnter(_syncRoot, 100)) {
        lockTaken = true;
        _counter++;
    } else {
        // 获取锁超时，可执行降级策略或记录告警日志
        throw new TimeoutException(“Failed to acquire lock within 100ms”);
    }
} finally {
    if (lockTaken) Monitor.Exit(_syncRoot);
}

为什么 Monitor.Wait/Pulse 不能与 lock 关键字混合使用？

许多开发者误以为在 lock 代码块内调用 Monitor.Wait 可以“智能地”释放锁并进入等待状态，结果往往导致程序死锁或抛出 SynchronizationLockException 异常。根本原因在于：Wait 方法要求调用线程必须已经持有目标对象的锁，并且它会原子性地执行“释放锁”和“进入对象等待队列”两个操作。而 lock 块在退出时会自动调用 Monitor.Exit，这个时机与 Wait 的释放机制相冲突，破坏了同步的原子性。

• 必须显式管理锁：要正确配合使用 Wait 和 Pulse（或 PulseAll），就必须放弃 lock 关键字，转而使用 Monitor.Enter 和 Monitor.Exit 进行显式的锁生命周期管理。
• Wait 的调用前提：只能在当前线程已成功获取锁之后调用，否则将立即抛出异常。
• Pulse 的信号特性：它仅通知目标对象等待队列中的单个线程（若有），而不会唤醒正在运行的线程；如果此时等待队列为空，该通知信号将被直接丢弃。

在经典的生产者-消费者模式中，消费者的 Get 方法必须采用如下显式写法（无法使用 lock 语法糖）：

public T Get() {
    Monitor.Enter(_syncRoot);
    try {
        while (_queue.Count == 0) {
            Monitor.Wait(_syncRoot); // 原子性地释放锁并进入等待状态
        }
        return _queue.Dequeue();
    } finally {
        Monitor.Exit(_syncRoot);
    }
}

锁的性能影响与高并发场景下的替代方案选择

需要明确的是，锁操作本身的开销很小，真正的性能损耗来源于“锁竞争”。当大量线程频繁争抢同一把锁时，lock 会导致线程串行化执行，反而降低 CPU 的利用效率。因此，在设计并发方案时，首先应评估：当前场景是否真的需要独占访问？

• 读多写少场景：如果业务以高频读取为主，偶尔伴随写入，那么 ReaderWriterLockSlim 的性能远胜于简单的 lock，它允许多个线程并发读，写入时独占。
• 简单的原子操作：如果仅仅是保护一个整数的递增、递减或比较交换，使用 Interlocked.Increment(ref _counter) 等原子操作可以实现真正的无锁化，性能比使用锁高出数个数量级。
• 并发集合类：对于队列、字典等集合操作，应优先考虑 System.Collections.Concurrent 命名空间下的 ConcurrentQueue、ConcurrentDictionary 等线程安全集合，它们内部采用了精巧的无锁算法或细粒度锁，性能更优。
• 跨进程同步需求：lock 和 Monitor 仅适用于单个进程内的线程同步。若需实现跨进程的同步，必须使用操作系统原语，如 Mutex（互斥体）或命名 Semaphore。

另一个至关重要的优化点是锁的粒度控制。切忌将整个方法体都用 lock 包裹。应当精确锁定那些真正访问共享状态的关键代码行。例如，在写入日志前进行的字符串拼接、时间格式化等非共享计算，完全可以在锁外部预先完成，这能显著缩短锁的持有时间，大幅提升系统的整体并发吞吐量。