C#的lock关键字如何实现线程同步？适用场景是什么？

lock关键字通过Monitor类实现线程互斥，确保同一时间仅一个线程执行临界区代码，防止竞态条件；推荐使用私有、静态、只读的引用类型对象作为锁，以避免死锁和同步失效；适用于保护共享数据、单例初始化、外部资源访问等场景，但在高并发下存在性能瓶颈、死锁风险及无法区分读写等问题；可选用ReaderWriterLockSlim、SemaphoreSlim、Interlocked、并发集合等替代方案以提升性能和灵活性。

C# 中的

lock

解决方案

lock

System.Threading.Monitor

lock (expression)

Monitor.Enter(expression)

try/finally

Monitor.Exit(expression)

expression

object

工作原理是这样的：当一个线程尝试进入

lock

expression

lock

lock

lock

一个非常重要的实践是，你锁定一个私有的、静态的、只读的

object

• 私有 (private)：防止外部代码获取到你的锁对象，从而导致意外的死锁或破坏你的同步机制。如果外部代码也能拿到这个对象并对其加锁，那你的内部逻辑就可能被外部的锁行为影响。
• 静态 (static)：如果你的锁是针对类级别的共享资源，那么它应该是静态的，这样所有实例都共享同一个锁。如果是非静态的，每个实例都会有自己的锁，这通常不是我们想要的线程同步。
• 只读 (readonly)：一旦初始化，锁对象就不会被改变。这避免了在运行时不小心将锁对象替换掉，导致同步失效。

来看一个简单的例子：

public class Counter
{
    private readonly object _lockObject = new object(); // 推荐的锁对象
    private int _count;

    public void Increment()
    {
        lock (_lockObject) // 确保每次只有一个线程能修改 _count
        {
            _count++;
            Console.WriteLine($"Current count: {_count}");
        }
    }

    public int GetCount()
    {
        // 读取操作也可能需要锁定，取决于业务逻辑和对数据一致性的要求
        // 如果_count的读取和写入是分离的，且读取不要求最新状态，可以不加锁
        // 但如果要求读取的是最新写入的值，或者读取本身涉及复杂操作，则仍需加锁
        lock (_lockObject)
        {
            return _count;
        }
    }
}

lock

关键字如何避免常见的线程安全问题？

在我看来，

lock

比如说，一个简单的

i++

i

i

i++

• 线程A读取

  i

  (假设为0)
• 线程B读取

  i

  (也为0)
• 线程A将

  i

  加1，并写回 (

  i

  变为1)
• 线程B将

  i

  加1，并写回 (

  i

  变为1)

结果

i

lock

lock

i

在哪些具体场景下，使用

lock

关键字是最佳实践？

我个人觉得，

lock

1. 保护共享内存中的数据结构： 这是最常见的场景。比如，你有一个静态的

   Dictionary

   或者一个

   List

   ，多个线程可能同时向其中添加、删除或修改元素。由于这些集合类型本身不是线程安全的，直接并发操作会导致数据损坏或运行时异常。这时候，用

   lock

   包裹对这些集合的所有修改操作，就能确保数据的一致性。

   private static readonly object _cacheLock = new object();
   private static Dictionary _dataCache = new Dictionary();
   
   public static void AddOrUpdateCache(string key, string value)
   {
       lock (_cacheLock)
       {
           _dataCache[key] = value;
       }
   }
   
   public static string GetFromCache(string key)
   {
       lock (_cacheLock)
       {
           return _dataCache.TryGetValue(key, out var value) ? value : null;
       }
   }

   你看，无论是写入还是读取，都通过同一个锁对象来协调，避免了潜在的冲突。

2. 管理单例模式的实例创建： 在多线程环境下，确保单例模式只创建一个实例是很有挑战性的。虽然现在有了

   Lazy

   这种更优雅的方案，但早期的双重检查锁定（Double-Checked Locking）模式就大量依赖

   lock

   来保证线程安全地创建单例。

   public class Singleton
   {
       private static Singleton _instance;
       private static readonly object _lock = new object();
   
       private Singleton() { } // 私有构造函数
   
       public static Singleton GetInstance()
       {
           if (_instance == null) // 第一次检查
           {
               lock (_lock) // 加锁
               {
                   if (_instance == null) // 第二次检查
                   {
                       _instance = new Singleton();
                   }
               }
           }
           return _instance;
       }
   }

   这种模式利用

   lock

   确保在实例真正创建时是互斥的。

3. 对外部资源的独占访问： 当你的应用程序需要访问一个外部资源，比如文件、数据库连接池中的某个连接，或者一个串口设备时，如果这个资源不支持并发访问，那么你就需要用

   lock

   来确保在任何时候只有一个线程能操作它。这可以防止资源争用导致的错误或数据损坏。

4. 控制特定逻辑流程的原子性： 有时候，你可能不只是要保护一个变量，而是要确保一系列相关的操作作为一个整体，不被其他线程打断。比如，一个复杂的业务逻辑涉及到多个步骤，这些步骤必须连续执行才能保证数据状态的正确性。

   lock

   可以把这些步骤打包成一个原子操作单元。

总的来说，当并发操作涉及对共享状态的修改，且这些修改必须是互斥的、原子性的，并且你对性能要求不是极端苛刻，同时锁的粒度可以接受时，

lock

lock

关键字的局限性与替代方案有哪些？

尽管

lock

稿定AI社区

在线AI创意灵感社区

下载

lock

1. 性能瓶颈： 这是最显而易见的。

   lock

   是一种粗粒度的锁，它强制所有尝试进入临界区的线程排队等待。在高并发、高竞争的场景下，大量线程频繁地争抢同一个锁会导致严重的性能开销，因为线程上下文切换和锁的获取/释放操作本身就是耗时的。想象一下，如果一个锁被持有时间很长，或者有非常多的线程在等待，整个系统的吞吐量会急剧下降。

2. 死锁风险：

   lock

   最让人头疼的问题之一就是容易引发死锁。当两个或多个线程各自持有一个锁，并尝试获取对方持有的锁时，就会发生死锁，它们会无限期地互相等待，导致程序停滞。例如：

   object lockA = new object();
   object lockB = new object();
   
   // 线程1
   lock (lockA)
   {
       Thread.Sleep(100); // 模拟工作
       lock (lockB) { /* ... */ }
   }
   
   // 线程2
   lock (lockB)
   {
       Thread.Sleep(100); // 模拟工作
       lock (lockA) { /* ... */ }
   }

   这种交叉锁定很容易导致死锁。解决死锁通常需要严格遵循锁的获取顺序，或者使用更复杂的策略。

3. 无法区分读写操作：

   lock

   提供的是排他锁，也就是说，无论是读取还是写入共享资源，都需要获取独占锁。在读多写少的场景下，这会大大降低并发性。比如，100个线程要读取一个共享数据，如果每次读取都需要独占锁，那么99个线程都得等着，这显然效率不高。

4. 不支持超时：

   lock

   是一种阻塞式操作，线程会无限期地等待直到获取到锁。如果锁永远无法释放（比如持有锁的线程崩溃了），等待的线程也会永远阻塞，这在某些需要响应性的应用中是不可接受的。

替代方案：

面对

lock

1. Monitor

   类：

   lock

   的底层就是

   Monitor

   。直接使用

   Monitor.Enter()

   ,

   Monitor.Exit()

   ,

   Monitor.TryEnter()

   可以提供更细粒度的控制，比如

   TryEnter

   允许你设置一个超时时间，避免无限等待。

   Monitor.Wait()

   和

   Monitor.Pulse()

   /

   PulseAll()

   则可以实现线程间的协作（一个线程等待某个条件满足，另一个线程通知它）。

2. ReaderWriterLockSlim

   ： 这是解决读写锁问题的好方案。它允许多个线程同时获取读锁，但在写入时，只有当没有其他读锁或写锁被持有时，才能获取写锁。这大大提高了读多写少场景下的并发性能。

3. SemaphoreSlim

   ： 信号量，用于限制同时访问某个资源的线程数量。比如，你有一个数据库连接池，只想允许最多N个线程同时使用连接，就可以用

   SemaphoreSlim

   来控制。它比

   lock

   更灵活，因为它不要求独占访问，而是限制并发数量。

4. Mutex

   ： 互斥体，与

   lock

   类似，但它可以在进程之间进行同步。如果你的同步需求跨越多个进程，

   Mutex

   是一个选择。

5. Interlocked

   类： 对于简单的原子操作，比如递增/递减整数、交换值等，

   Interlocked

   类提供了高性能的原子操作方法，无需使用锁。它直接利用CPU的原子指令，效率非常高，且不会引起上下文切换。

6. 并发集合（

   System.Collections.Concurrent

   命名空间）： 这是在多线程环境中处理集合的首选。例如

   ConcurrentDictionary

   、

   ConcurrentQueue

   、

   ConcurrentBag

   等。这些集合内部已经实现了线程安全，你无需自己加锁，它们通常采用无锁（lock-free）或细粒度锁的算法，性能远超手动加

   lock

   。

7. 任务并行库 (TPL) 和

   async/await

   ： 虽然这不是直接的同步原语，但它们改变了我们编写并发代码的方式。通过使用异步编程，可以避免阻塞线程，从而提高应用程序的响应性和吞吐量。当然，即使使用

   async/await

   ，对于共享状态的访问，你仍然需要上述的同步机制。

选择哪种同步机制，往往取决于具体的场景、对性能的要求以及对复杂度的容忍度。

lock

ReaderWriterLockSlim

Monitor