1. 为什么我们需要线程同步当你在C#中编写多线程程序时可能会遇到这样的情况两个线程同时修改同一个变量结果却不是你预期的。这就是典型的线程安全问题。想象一下你和朋友同时往同一个银行账户存钱如果没有正确的同步机制最终余额可能会出错。线程同步的核心目标是确保多个线程对共享资源的有序访问。在C#中主要有三种同步机制lock关键字、Monitor类和Mutex类。每种机制都有其适用场景和性能特点。重要提示错误的同步方式可能导致死锁两个线程互相等待对方释放资源或性能下降过度同步导致线程阻塞。2. lock关键字最常用的同步方式2.1 lock的基本用法lock是C#中最简单直接的同步机制。它的语法非常简洁private readonly object _lockObj new object(); void ThreadSafeMethod() { lock (_lockObj) { // 临界区代码 } }这里有几个关键点需要注意锁对象应该是私有的避免外部代码也能锁定它锁对象应该是引用类型通常是object锁对象应该是只读的readonly防止意外修改2.2 lock的工作原理lock实际上是Monitor类的语法糖。编译器会将上面的代码转换为类似下面的形式object __lockObj _lockObj; bool __lockTaken false; try { Monitor.Enter(__lockObj, ref __lockTaken); // 临界区代码 } finally { if (__lockTaken) Monitor.Exit(__lockObj); }这种转换确保了即使在临界区代码抛出异常的情况下锁也能被正确释放。2.3 lock的性能考量虽然lock使用方便但不恰当的使用会导致性能问题锁的粒度锁的范围应该尽可能小只保护真正需要同步的代码锁的持续时间临界区代码执行时间越长其他线程等待的时间就越长锁的争用多个线程频繁争用同一个锁会导致性能下降实测数据在普通PC上无争用情况下lock/unlock操作大约需要20-50纳秒在高争用情况下性能会显著下降。3. Monitor类更灵活的同步控制3.1 Monitor的基本用法Monitor类提供了比lock更灵活的控制能力。基本用法如下private readonly object _monitorObj new object(); void ThreadSafeMethod() { Monitor.Enter(_monitorObj); try { // 临界区代码 } finally { Monitor.Exit(_monitorObj); } }看起来和lock很相似但Monitor还提供了额外的功能。3.2 Monitor的高级功能3.2.1 TryEnter方法if (Monitor.TryEnter(_monitorObj, 1000)) // 尝试获取锁最多等待1秒 { try { // 临界区代码 } finally { Monitor.Exit(_monitorObj); } } else { // 获取锁超时处理 }这个方法可以避免无限期等待有助于预防死锁。3..2 Wait/Pulse/PulseAllMonitor还实现了类似条件变量的功能private readonly object _conditionObj new object(); private bool _condition false; void WaitForCondition() { Monitor.Enter(_conditionObj); while (!_condition) { Monitor.Wait(_conditionObj); // 释放锁并等待 } // 条件满足后的处理 Monitor.Exit(_conditionObj); } void SetCondition() { Monitor.Enter(_conditionObj); _condition true; Monitor.Pulse(_conditionObj); // 唤醒一个等待线程 // Monitor.PulseAll(_conditionObj); // 唤醒所有等待线程 Monitor.Exit(_conditionObj); }这种模式常用于生产者-消费者场景。3.3 Monitor的注意事项Enter和Exit必须成对出现且Exit必须在finally块中调用Wait会暂时释放锁并在被唤醒后重新获取锁Pulse/PulseAll必须在持有锁的情况下调用错误的调用顺序可能导致死锁或异常4. Mutex跨进程的同步机制4.1 Mutex的基本用法Mutex互斥体比lock和Monitor更重量级但支持跨进程同步// 本地Mutex using var mutex new Mutex(); mutex.WaitOne(); try { // 临界区代码 } finally { mutex.ReleaseMutex(); } // 命名Mutex跨进程 bool createdNew; using var namedMutex new Mutex(true, Global\\MyNamedMutex, out createdNew); try { if (!createdNew) { Console.WriteLine(另一个实例已经在运行); return; } // 临界区代码 } finally { namedMutex.ReleaseMutex(); }4.2 Mutex的特殊用途单实例应用程序确保程序只有一个实例在运行跨进程资源共享协调多个进程对共享资源的访问长时间运行的临界区适合保护执行时间较长的操作4.3 Mutex的性能考虑Mutex是内核对象每次等待和释放都涉及用户态到内核态的切换因此性能比lock和Monitor差很多。实测数据Mutex的获取和释放操作大约需要几微秒到几十微秒比lock慢100倍以上。5. 实战中的线程同步问题5.1 死锁预防死锁的四个必要条件互斥条件占有并等待非抢占条件循环等待预防死锁的策略锁的顺序所有线程按相同顺序获取锁锁超时使用TryEnter或带超时的WaitOne锁层次设计锁的层次结构避免循环等待5.2 锁的粒度选择细粒度锁保护少量数据减少争用但管理复杂粗粒度锁保护大量数据管理简单但争用严重经验法则开始时使用较粗的粒度根据性能测试结果逐步细化。5.3 无锁编程替代方案在某些场景下可以考虑无锁编程Interlocked类简单的原子操作Concurrent集合线程安全的集合类Immutable集合不可变数据结构6. 性能对比与选择指南6.1 同步机制性能对比机制适用范围性能(无争用)性能(高争用)跨进程lock单进程多线程20-50ns较差否Monitor单进程多线程20-50ns较差否Mutex跨进程几μs-几十μs很差是6.2 选择指南单进程多线程同步优先考虑lock需要超时或条件变量使用Monitor跨进程同步必须使用Mutex高性能场景考虑无锁编程或更高级的同步原语7. 常见问题排查7.1 死锁诊断症状程序挂起CPU使用率低 诊断方法使用Visual Studio的并行堆栈窗口使用Process Explorer查看线程等待链代码审查锁的获取顺序7.2 性能问题症状CPU使用率高但吞吐量低 优化方向减少锁的争用缩小临界区、使用更细粒度的锁降低锁的持有时间将耗时操作移出临界区考虑无锁数据结构7.3 同步遗漏症状偶发的数据损坏或不一致 检查点所有共享数据的访问是否都受到保护是否有多处访问同一数据的代码路径是否正确地处理了异常情况8. 实际案例解析8.1 线程安全的缓存实现public class ThreadSafeCacheTKey, TValue { private readonly DictionaryTKey, TValue _cache new DictionaryTKey, TValue(); private readonly object _lock new object(); public TValue GetOrAdd(TKey key, FuncTKey, TValue valueFactory) { lock (_lock) { if (_cache.TryGetValue(key, out var value)) return value; value valueFactory(key); _cache.Add(key, value); return value; } } }这个实现确保了缓存的线程安全但valueFactory的执行也在锁内可能会影响性能。更高级的实现可以使用双重检查锁定模式。8.2 生产者-消费者队列public class BlockingQueueT { private readonly QueueT _queue new QueueT(); private readonly object _lock new object(); public void Enqueue(T item) { lock (_lock) { _queue.Enqueue(item); Monitor.Pulse(_lock); } } public T Dequeue() { lock (_lock) { while (_queue.Count 0) Monitor.Wait(_lock); return _queue.Dequeue(); } } }这个实现使用了Monitor的Wait/Pulse机制当队列为空时消费者线程会等待直到有新的元素被加入。9. 高级话题与扩展阅读9.1 读写锁ReaderWriterLockSlim适用于读多写少的场景private readonly ReaderWriterLockSlim _rwLock new ReaderWriterLockSlim(); void ReadOperation() { _rwLock.EnterReadLock(); try { // 只读操作 } finally { _rwLock.ExitReadLock(); } } void WriteOperation() { _rwLock.EnterWriteLock(); try { // 写操作 } finally { _rwLock.ExitWriteLock(); } }9.2 信号量Semaphore限制同时访问资源的线程数量private readonly Semaphore _semaphore new Semaphore(3, 3); // 最多3个线程同时访问 void LimitedAccessMethod() { _semaphore.WaitOne(); try { // 受保护的代码 } finally { _semaphore.Release(); } }9.3 屏障Barrier协调多个线程的执行阶段var barrier new Barrier(3); // 等待3个线程 void PhaseMethod() { // 阶段1代码 barrier.SignalAndWait(); // 阶段2代码 }10. 调试与性能分析技巧10.1 Visual Studio调试工具并行堆栈窗口查看所有线程的调用堆栈并行任务窗口监控所有任务的状态并发可视化工具分析线程活动和锁争用10.2 性能分析使用Stopwatch测量临界区执行时间使用性能分析器识别热点监控锁争用率contention rate10.3 代码审查要点检查所有锁对象的生命周期验证锁的获取和释放是否成对出现评估锁的粒度和持有时间检查是否存在潜在的锁顺序问题在实际项目中我发现很多线程问题都源于对锁的误解或不当使用。一个常见的错误是在持有锁的情况下调用外部代码这可能导致死锁或性能问题。另一个陷阱是忘记在异常情况下释放锁这会导致程序最终无法继续执行。
C#线程同步机制：lock、Monitor与Mutex详解
1. 为什么我们需要线程同步当你在C#中编写多线程程序时可能会遇到这样的情况两个线程同时修改同一个变量结果却不是你预期的。这就是典型的线程安全问题。想象一下你和朋友同时往同一个银行账户存钱如果没有正确的同步机制最终余额可能会出错。线程同步的核心目标是确保多个线程对共享资源的有序访问。在C#中主要有三种同步机制lock关键字、Monitor类和Mutex类。每种机制都有其适用场景和性能特点。重要提示错误的同步方式可能导致死锁两个线程互相等待对方释放资源或性能下降过度同步导致线程阻塞。2. lock关键字最常用的同步方式2.1 lock的基本用法lock是C#中最简单直接的同步机制。它的语法非常简洁private readonly object _lockObj new object(); void ThreadSafeMethod() { lock (_lockObj) { // 临界区代码 } }这里有几个关键点需要注意锁对象应该是私有的避免外部代码也能锁定它锁对象应该是引用类型通常是object锁对象应该是只读的readonly防止意外修改2.2 lock的工作原理lock实际上是Monitor类的语法糖。编译器会将上面的代码转换为类似下面的形式object __lockObj _lockObj; bool __lockTaken false; try { Monitor.Enter(__lockObj, ref __lockTaken); // 临界区代码 } finally { if (__lockTaken) Monitor.Exit(__lockObj); }这种转换确保了即使在临界区代码抛出异常的情况下锁也能被正确释放。2.3 lock的性能考量虽然lock使用方便但不恰当的使用会导致性能问题锁的粒度锁的范围应该尽可能小只保护真正需要同步的代码锁的持续时间临界区代码执行时间越长其他线程等待的时间就越长锁的争用多个线程频繁争用同一个锁会导致性能下降实测数据在普通PC上无争用情况下lock/unlock操作大约需要20-50纳秒在高争用情况下性能会显著下降。3. Monitor类更灵活的同步控制3.1 Monitor的基本用法Monitor类提供了比lock更灵活的控制能力。基本用法如下private readonly object _monitorObj new object(); void ThreadSafeMethod() { Monitor.Enter(_monitorObj); try { // 临界区代码 } finally { Monitor.Exit(_monitorObj); } }看起来和lock很相似但Monitor还提供了额外的功能。3.2 Monitor的高级功能3.2.1 TryEnter方法if (Monitor.TryEnter(_monitorObj, 1000)) // 尝试获取锁最多等待1秒 { try { // 临界区代码 } finally { Monitor.Exit(_monitorObj); } } else { // 获取锁超时处理 }这个方法可以避免无限期等待有助于预防死锁。3..2 Wait/Pulse/PulseAllMonitor还实现了类似条件变量的功能private readonly object _conditionObj new object(); private bool _condition false; void WaitForCondition() { Monitor.Enter(_conditionObj); while (!_condition) { Monitor.Wait(_conditionObj); // 释放锁并等待 } // 条件满足后的处理 Monitor.Exit(_conditionObj); } void SetCondition() { Monitor.Enter(_conditionObj); _condition true; Monitor.Pulse(_conditionObj); // 唤醒一个等待线程 // Monitor.PulseAll(_conditionObj); // 唤醒所有等待线程 Monitor.Exit(_conditionObj); }这种模式常用于生产者-消费者场景。3.3 Monitor的注意事项Enter和Exit必须成对出现且Exit必须在finally块中调用Wait会暂时释放锁并在被唤醒后重新获取锁Pulse/PulseAll必须在持有锁的情况下调用错误的调用顺序可能导致死锁或异常4. Mutex跨进程的同步机制4.1 Mutex的基本用法Mutex互斥体比lock和Monitor更重量级但支持跨进程同步// 本地Mutex using var mutex new Mutex(); mutex.WaitOne(); try { // 临界区代码 } finally { mutex.ReleaseMutex(); } // 命名Mutex跨进程 bool createdNew; using var namedMutex new Mutex(true, Global\\MyNamedMutex, out createdNew); try { if (!createdNew) { Console.WriteLine(另一个实例已经在运行); return; } // 临界区代码 } finally { namedMutex.ReleaseMutex(); }4.2 Mutex的特殊用途单实例应用程序确保程序只有一个实例在运行跨进程资源共享协调多个进程对共享资源的访问长时间运行的临界区适合保护执行时间较长的操作4.3 Mutex的性能考虑Mutex是内核对象每次等待和释放都涉及用户态到内核态的切换因此性能比lock和Monitor差很多。实测数据Mutex的获取和释放操作大约需要几微秒到几十微秒比lock慢100倍以上。5. 实战中的线程同步问题5.1 死锁预防死锁的四个必要条件互斥条件占有并等待非抢占条件循环等待预防死锁的策略锁的顺序所有线程按相同顺序获取锁锁超时使用TryEnter或带超时的WaitOne锁层次设计锁的层次结构避免循环等待5.2 锁的粒度选择细粒度锁保护少量数据减少争用但管理复杂粗粒度锁保护大量数据管理简单但争用严重经验法则开始时使用较粗的粒度根据性能测试结果逐步细化。5.3 无锁编程替代方案在某些场景下可以考虑无锁编程Interlocked类简单的原子操作Concurrent集合线程安全的集合类Immutable集合不可变数据结构6. 性能对比与选择指南6.1 同步机制性能对比机制适用范围性能(无争用)性能(高争用)跨进程lock单进程多线程20-50ns较差否Monitor单进程多线程20-50ns较差否Mutex跨进程几μs-几十μs很差是6.2 选择指南单进程多线程同步优先考虑lock需要超时或条件变量使用Monitor跨进程同步必须使用Mutex高性能场景考虑无锁编程或更高级的同步原语7. 常见问题排查7.1 死锁诊断症状程序挂起CPU使用率低 诊断方法使用Visual Studio的并行堆栈窗口使用Process Explorer查看线程等待链代码审查锁的获取顺序7.2 性能问题症状CPU使用率高但吞吐量低 优化方向减少锁的争用缩小临界区、使用更细粒度的锁降低锁的持有时间将耗时操作移出临界区考虑无锁数据结构7.3 同步遗漏症状偶发的数据损坏或不一致 检查点所有共享数据的访问是否都受到保护是否有多处访问同一数据的代码路径是否正确地处理了异常情况8. 实际案例解析8.1 线程安全的缓存实现public class ThreadSafeCacheTKey, TValue { private readonly DictionaryTKey, TValue _cache new DictionaryTKey, TValue(); private readonly object _lock new object(); public TValue GetOrAdd(TKey key, FuncTKey, TValue valueFactory) { lock (_lock) { if (_cache.TryGetValue(key, out var value)) return value; value valueFactory(key); _cache.Add(key, value); return value; } } }这个实现确保了缓存的线程安全但valueFactory的执行也在锁内可能会影响性能。更高级的实现可以使用双重检查锁定模式。8.2 生产者-消费者队列public class BlockingQueueT { private readonly QueueT _queue new QueueT(); private readonly object _lock new object(); public void Enqueue(T item) { lock (_lock) { _queue.Enqueue(item); Monitor.Pulse(_lock); } } public T Dequeue() { lock (_lock) { while (_queue.Count 0) Monitor.Wait(_lock); return _queue.Dequeue(); } } }这个实现使用了Monitor的Wait/Pulse机制当队列为空时消费者线程会等待直到有新的元素被加入。9. 高级话题与扩展阅读9.1 读写锁ReaderWriterLockSlim适用于读多写少的场景private readonly ReaderWriterLockSlim _rwLock new ReaderWriterLockSlim(); void ReadOperation() { _rwLock.EnterReadLock(); try { // 只读操作 } finally { _rwLock.ExitReadLock(); } } void WriteOperation() { _rwLock.EnterWriteLock(); try { // 写操作 } finally { _rwLock.ExitWriteLock(); } }9.2 信号量Semaphore限制同时访问资源的线程数量private readonly Semaphore _semaphore new Semaphore(3, 3); // 最多3个线程同时访问 void LimitedAccessMethod() { _semaphore.WaitOne(); try { // 受保护的代码 } finally { _semaphore.Release(); } }9.3 屏障Barrier协调多个线程的执行阶段var barrier new Barrier(3); // 等待3个线程 void PhaseMethod() { // 阶段1代码 barrier.SignalAndWait(); // 阶段2代码 }10. 调试与性能分析技巧10.1 Visual Studio调试工具并行堆栈窗口查看所有线程的调用堆栈并行任务窗口监控所有任务的状态并发可视化工具分析线程活动和锁争用10.2 性能分析使用Stopwatch测量临界区执行时间使用性能分析器识别热点监控锁争用率contention rate10.3 代码审查要点检查所有锁对象的生命周期验证锁的获取和释放是否成对出现评估锁的粒度和持有时间检查是否存在潜在的锁顺序问题在实际项目中我发现很多线程问题都源于对锁的误解或不当使用。一个常见的错误是在持有锁的情况下调用外部代码这可能导致死锁或性能问题。另一个陷阱是忘记在异常情况下释放锁这会导致程序最终无法继续执行。
