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

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

先说一个核心结论：lock 并不是一个万能的同步开关。它只在用对对象、写对范围、避开常见陷阱时，才能真正保障线程安全。简单来说，绝大多数日常场景下，用 lock 就足够了；但一旦你需要等待特定条件、唤醒其他线程，或者进行超时控制，就必须切换到 Monitor 类。

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

新手常犯的一个错误，是在方法内部每次都用 new object() 来加锁，或者图省事直接 lock(this)。这两种写法，本质上等于没锁——因为锁对象不唯一，线程之间根本无法形成有效的互斥。

• new object()：每次调用都新建一个实例，不同线程拿到的是完全不同的对象，lock 自然就失效了。
• this：这是一个公开引用，外部代码也可能用它来加锁，极易导致意外的死锁或逻辑干扰。
• 字符串字面量：比如 lock(“mykey”)，由于字符串驻留机制，它可能在多个类之间被共享，同样存在风险。

那么，正确的做法是什么？答案是声明一个 private readonly object 字段。更推荐使用 static readonly（静态只读），以确保锁对象的生命周期与需要保护的资源访问范围完全一致。来看个例子：

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

lock 和 Monitor.Enter/Exit 的等价性与关键差异

表面上看，lock 语法很简洁，但它的背后其实是编译器生成的一套标准操作：一个 try-finally 块，加上对 Monitor.Enter(..., ref lockTaken) 的调用。从 .NET Framework 4.0 开始，这个 ref bool 参数变得至关重要——它专门用来应对 ThreadAbortException 这类极端的中断情况，确保锁不会“卡死”在系统中。

• lock 的优势：自动处理异常安全释放，你无法绕过它去手动调用 Monitor.Exit，这减少了出错的可能。
• Monitor.Enter 的灵活性：它允许你先检查 taken 标志，再决定是否执行临界区代码，这为实现“尝试获取锁”的逻辑提供了可能。
• 关键差异点：如果你需要为锁操作设置一个超时（比如最多等待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 块在结束时会自动调用 Exit，这个时机是不可控的，两者机制存在冲突。

• 必须显式管理：要配合使用 Wait 和 Pulse，就必须使用 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) 可以实现真正的零开销，性能比锁高出一个数量级。
• 并发集合：对于集合操作，优先考虑 ConcurrentQueue、ConcurrentDictionary 等线程安全集合，它们内部已经做了精妙的无锁或细粒度锁优化。
• 跨进程同步：lock 和 Monitor 都只作用于单个进程内部。要实现跨进程同步，必须使用 Mutex（互斥体）或命名信号量。

还有一个最容易被忽略的优化点：锁的粒度。切忌将整个方法体都用 lock 包裹起来。应该只锁住那些真正访问共享状态的关键代码行。例如，在写入日志前进行的字符串拼接、时间格式化等计算，完全可以在锁外部完成，这能显著减少锁的持有时间，提升并发性能。