线程同步是多线程编程中确保共享资源安全访问的关键机制，C#提供lock、Monitor、Mutex、SemaphoreSlim、ReaderWriterLockSlim、Interlocked等工具，以及并发集合和Channel等现代模式，用于解决竞态条件、数据不一致等问题，选择合适机制需权衡场景、性能与复杂度。
C#中的线程同步，说白了，就是为了让多个线程在访问共享资源时，能“排队”或者“协商”，避免互相干扰，导致数据混乱或者程序崩溃。想象一下，如果多个人同时去一个银行柜台取钱，但只有一个柜员，大家又不按顺序来，那场面肯定会乱套，账目也会出错。线程同步就是那个维持秩序的机制，确保每次只有一个线程能够安全地操作那份共享的“钱”。它在多线程编程中至关重要，是保证程序正确性和数据完整性的基石。
解决方案
在C#中实现线程同步，我们有一系列工具和策略，从最基础的锁机制到更高级的并发集合，每种都有其适用场景和考量。
1.
lock
关键字：最常见也最直观的互斥锁
这是C#中最简单、最常用的同步机制。它确保在给定时间内，只有一个线程可以进入被锁定的代码块。
public class Counter{ private int _count = 0; private readonly object _lockObject = new object(); // 用于锁定的私有对象 public void Increment() { lock (_lockObject) // 锁定_lockObject，确保同一时间只有一个线程能执行这里的代码 { _count++; Console.WriteLine($"Incremented to: {_count}"); } } public int GetCount() { lock (_lockObject) // 读取时也需要锁定，防止在读取过程中_count被其他线程修改 { return _count; } }}
我个人觉得，对于大多数简单的共享资源访问，
lock
关键字是首选，因为它简洁、易懂，而且编译器会确保锁的正确释放（即使发生异常）。
2.
Monitor
类：更灵活的互斥和信号机制
Monitor
类提供了比
lock
关键字更细粒度的控制。实际上，
lock
关键字在编译时就是被翻译成了
Monitor.Enter
和
Monitor.Exit
调用（加上
try/finally
块）。
Monitor
还可以通过
Wait
、
Pulse
和
PulseAll
方法实现线程间的协作和通知。
public class ProducerConsumer{ private readonly Queue _queue = new Queue(); private readonly object _lockObject = new object(); private const int Capacity = 5; public void Produce(int item) { lock (_lockObject) { while (_queue.Count == Capacity) { Console.WriteLine("Queue is full. Producer waiting..."); Monitor.Wait(_lockObject); // 队列满时，生产者等待 } _queue.Enqueue(item); Console.WriteLine($"Produced: {item}. Queue size: {_queue.Count}"); Monitor.PulseAll(_lockObject); // 通知所有等待的消费者 } } public int Consume() { lock (_lockObject) { while (_queue.Count == 0) { Console.WriteLine("Queue is empty. Consumer waiting..."); Monitor.Wait(_lockObject); // 队列空时，消费者等待 } int item = _queue.Dequeue(); Console.WriteLine($"Consumed: {item}. Queue size: {_queue.Count}"); Monitor.PulseAll(_lockObject); // 通知所有等待的生产者 return item; } }}
当我们需要实现生产者-消费者模式或者更复杂的线程间通信时，
Monitor
的
Wait
/
Pulse
机制就显得非常有用。
3.
Mutex
(互斥体)：跨进程的同步
Mutex
与
lock
或
Monitor
类似，但它可以在多个进程之间实现同步。这意味着，即使是完全独立的应用程序实例，也可以使用同一个
Mutex
来协调对共享资源的访问（例如，确保一个应用程序只有一个实例在运行）。
// 示例：确保应用程序单实例运行public class SingleInstanceApp{ private static Mutex _appMutex; public static bool IsSingleInstance() { // 尝试创建或打开一个命名Mutex _appMutex = new Mutex(true, "MyUniqueApplicationMutexName", out bool createdNew); return createdNew; // 如果createdNew为true，表示当前是第一个实例 } public static void ReleaseMutex() { _appMutex?.ReleaseMutex(); _appMutex?.Dispose(); }}
对于需要跨进程同步的场景，
Mutex
是不可替代的工具。但它的开销比
lock
大，所以只在必要时使用。
4.
Semaphore
和
SemaphoreSlim
：限制并发访问数量
信号量用于限制同时访问某个资源的线程数量。例如，你可能有一个数据库连接池，只允许最多10个线程同时获取连接。
SemaphoreSlim
是
Semaphore
的轻量级版本，适用于进程内的同步，性能更好。
public class ResourcePool{ private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(3); // 允许3个线程同时访问 private int _resourceCounter = 0; public async Task AccessResourceAsync() { await _semaphore.WaitAsync(); // 等待获取信号量 try { int currentAccessId = Interlocked.Increment(ref _resourceCounter); Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} acquired resource. Access ID: {currentAccessId}"); await Task.Delay(1000); // 模拟资源访问耗时 Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} finished resource access. Access ID: {currentAccessId}"); } finally { _semaphore.Release(); // 释放信号量 } }}
在我看来，
SemaphoreSlim
在处理资源池、限制并发请求数量等场景时，比手动管理锁和计数器要优雅得多。
5.
ReaderWriterLockSlim
：读写锁，优化读多写少场景
当一个资源被频繁读取但很少写入时，传统的互斥锁会降低并发性（因为读操作之间也会互相阻塞）。
ReaderWriterLockSlim
允许多个线程同时读取资源，但在写入时会独占资源。
public class CachedData{ private readonly Dictionary _cache = new Dictionary(); private readonly ReaderWriterLockSlim _rwLock = new ReaderWriterLockSlim(); public string GetValue(string key) { _rwLock.EnterReadLock(); // 进入读模式 try { return _cache.ContainsKey(key) ? _cache[key] : null; } finally { _rwLock.ExitReadLock(); // 退出读模式 } } public void SetValue(string key, string value) { _rwLock.EnterWriteLock(); // 进入写模式 try { _cache[key] = value; } finally { _rwLock.ExitWriteLock(); // 退出写模式 } }}
这个工具在我处理高性能缓存或配置读取时，能显著提升并发度，因为大部分操作都是读取。
6.
Interlocked
类：原子操作
对于简单的数值类型（如
int
,
long
）的增量、减量或交换操作，
Interlocked
类提供了原子操作，这意味着这些操作在多线程环境下是线程安全的，不需要额外的锁。它的性能通常比使用
lock
更好。
public class AtomicCounter{ private int _count = 0; public void Increment() { Interlocked.Increment(ref _count); // 原子增量 } public int GetCount() { return Interlocked.CompareExchange(ref _count, _count, _count); // 原子读取，等同于直接返回_count，但确保了原子性 }}
当只需要对一个简单变量进行原子更新时，
Interlocked
是一个非常高效的选择。
为什么我们需要线程同步？不进行同步会有什么潜在风险？
说实话，这个问题问得非常到位，因为很多人在写多线程代码时，往往只想着“并行”，而忽略了“同步”的重要性，直到bug出现才追悔莫及。
我们需要线程同步的核心原因，在于多线程环境下对共享资源的并发访问可能导致一系列灾难性的后果，最常见也最头疼的就是“竞态条件”（Race Condition）。
竞态条件（Race Condition）：当多个线程尝试同时访问和修改同一个共享资源时，最终结果的正确性取决于线程执行的时序，这种时序是不可预测的。举个最经典的例子，如果两个线程都想对一个共享的计数器
_count
执行
_count++
操作：
线程A读取
_count
(假设当前是0)。线程B读取
_count
(也是0)。线程A将
_count
加1 (变成1)。线程B将
_count
加1 (变成1)。最终结果是
_count
变成了1，而不是期望的2。这就像两个人同时从一个空的银行账户里取钱，因为系统没有同步，他们都看到了“余额充足”的假象，结果却只扣了一次钱。这种错误非常隐蔽，因为它不总是发生，只有在特定的线程调度时序下才会显现，导致难以复现和调试。
数据不一致性：竞态条件直接导致的就是数据不一致。除了上面计数器的例子，想象一下一个复杂对象，多个字段需要同时更新，但如果只更新了一部分字段，另一个线程就读取了这个“半成品”状态，那么得到的数据就是错误的，可能会引发后续的逻辑错误甚至程序崩溃。
死锁（Deadlock）：这是多线程编程中最令人头疼的问题之一。当两个或多个线程互相持有对方需要的资源，并都在等待对方释放资源时，就会发生死锁。它们会永远等待下去，导致程序卡住，无法继续执行。例如：
线程A获取了资源X的锁。线程B获取了资源Y的锁。线程A尝试获取资源Y的锁（但Y被B持有）。线程B尝试获取资源X的锁（但X被A持有）。结果就是A和B都无限期地等待，程序陷入僵局。
活锁（Livelock）：活锁不如死锁常见，但同样危险。它指的是线程虽然没有被阻塞，但它们却在不断地改变状态，以响应其他线程的动作，结果导致没有任何实际进展。它们都在“谦让”，但最终谁也无法完成任务。比如两个人同时过独木桥，发现对方也过来了，于是都退回去，然后又同时尝试，又退回去，循环往复。
性能下降：虽然线程同步是为了保证正确性，但过度或不恰当的同步也会带来性能开销。锁的获取和释放本身就需要时间，如果锁粒度过大，导致大量线程长时间等待，那么程序的并行性就会大大降低，甚至不如单线程执行效率高。
所以，线程同步是多线程编程中不可或缺的环节。它就像交通规则，虽然会限制车辆的速度和自由，但却是保证整个交通系统安全、高效运行的关键。
在实际开发中，选择哪种线程同步机制更合适？
这没有一个放之四海而皆准的答案，更多的是一种权衡和艺术。在我看来，选择合适的同步机制，就像是选择合适的工具来解决一个问题，你需要考虑问题的性质、性能要求、代码复杂度和可维护性。
1. 优先考虑
lock
关键字：对于大多数简单的共享资源访问，尤其是在方法内部或者一个相对小的代码块中，
lock
关键字是我的首选。它简单、直接、易于理解和使用，而且C#编译器会确保锁的正确释放。如果你不确定用什么，先从
lock
开始，它能解决80%的线程同步问题。
2. 考虑
Monitor
的场景：当你需要更复杂的线程协作，比如生产者-消费者模式，需要线程等待特定条件（如队列满/空）并被其他线程通知时，
Monitor.Wait
和
Monitor.Pulse/PulseAll
就显得非常强大。它提供了比
lock
更细粒度的控制能力。
3.
ReaderWriterLockSlim
用于读多写少：如果你的共享资源是“读多写少”的类型（比如一个缓存、配置对象），那么
ReaderWriterLockSlim
是一个极好的选择。它允许大量读操作同时进行，只有在写操作时才独占，能显著提升并发性能。这是我处理高性能数据访问时经常会用到的。
4.
SemaphoreSlim
用于资源限制：当你需要限制同时访问某个资源的线程数量时，比如数据库连接池、API调用限流，
SemaphoreSlim
是最直接和优雅的解决方案。它能有效地控制并发度，防止资源过载。
5.
Interlocked
用于原子操作：对于简单的数值类型（
int
,
long
）的原子增减、交换或比较交换操作，
Interlocked
类是最高效的。它避免了锁的开销，性能极佳。如果只是一个计数器或者标志位，别犹豫，用
Interlocked
。
6.
Mutex
用于跨进程同步：这是比较特殊的场景，只有当你需要在多个独立的应用程序进程之间进行同步时，才需要考虑
Mutex
。比如确保你的应用程序只有一个实例在运行，或者协调不同进程对某个共享文件或硬件设备的访问。它比进程内同步的开销大，所以不要滥用。
7. 现代并发集合 (
Concurrent Collections
)：在我看来，这是C#并发编程的一大福音。例如
ConcurrentDictionary
、
ConcurrentQueue
、
ConcurrentBag
等。这些集合内部已经实现了线程安全，通常比你自己手动加锁的
Dictionary
或
Queue
性能更好，而且代码更简洁。如果你的共享资源是一个集合，首先考虑使用这些并发集合，它们能大大简化你的代码，并减少出错的可能性。
8.
async/await
和
Task Parallel Library (TPL)
：虽然
async/await
主要用于异步编程，解决I/O密集型操作的响应性问题，而不是直接解决共享资源的同步问题，但它改变了我们编写并发代码的方式。TPL (如
Parallel.For
,
Parallel.ForEach
) 则专注于CPU密集型任务的并行化。在使用这些现代工具时，你仍然需要警惕共享状态的访问，并结合上述同步机制来保护它们。我经常会看到有人误以为用了
async/await
就不需要同步了，这是个常见的误区。
总结一下我的选择逻辑：
简单互斥：
lock
(首选)读写分离：
ReaderWriterLockSlim
资源限流：
SemaphoreSlim
原子操作：
Interlocked
集合操作：
Concurrent Collections
复杂协作：
Monitor
跨进程：
Mutex
选择的关键在于理解每种机制的优缺点和适用场景，避免过度同步（导致性能下降）和同步不足（导致数据错误）。
除了传统的锁机制，C#还有哪些现代的并发编程模式和工具？
C#和.NET平台在并发编程方面一直在进化，除了那些底层的锁机制，我们现在有更多高级、更抽象的工具和模式，它们旨在简化并发代码的编写，提高可读性和可维护性，同时尽可能地减少手动管理锁的需要。
1.
async/await
异步编程模型：这不是一个直接的线程同步机制，但它彻底改变了C#中处理I/O密集型和长时间运行操作的方式。它允许你在等待一个操作完成时释放当前线程，让线程去做其他事情，从而提高应用程序的响应性。虽然
async/await
本身不提供锁，但它鼓励了一种“无共享状态”或“最小共享状态”的编程风格，因为异步方法通常返回
Task
，数据通过
Task
的结果传递，而不是通过共享字段。当然，如果异步方法内部仍然访问共享的可变状态，那么传统的同步机制依然是必要的。我个人觉得，
async/await
是现代C#应用开发中不可或缺的一部分，尤其是在UI、Web服务和网络通信中。
2.
Task Parallel Library (TPL)
：TPL 是一组用于并行编程的API，它使得编写并行代码变得更加容易和高效。
Parallel.For
和
Parallel.ForEach
： 这些方法可以让你并行地迭代循环，自动管理线程池和任务调度。它们非常适合CPU密集型计算，能够充分利用多核处理器的能力。
// 示例：并行计算数组平方 int[] numbers = Enumerable.Range(0, 1000000).ToArray(); long[] squares = new long[numbers.Length]; Parallel.For(0, numbers.Length, i => { squares[i] = (long)numbers[i] * numbers[i]; });
Parallel.Invoke
： 用于并行执行一组Action委托。
Task
和
Task
： TPL的核心是
Task
对象，它代表一个异步操作。你可以创建、启动和等待
Task
，并通过
ContinueWith
来链式执行操作。
Task
是
async/await
的基础。
3. 并发集合 (Concurrent Collections)：正如前面提到的，这是我非常推崇的一类工具。它们是 .NET Framework 4.0 引入的，位于
System.Collections.Concurrent
命名空间下。这些集合（如
ConcurrentDictionary
,
ConcurrentQueue
,
ConcurrentBag
,
ConcurrentStack
) 在内部已经实现了线程安全，这意味着你无需手动加锁就能安全地在多线程环境下使用它们。它们通常采用无锁或细粒度锁的算法，比手动对非并发集合加
lock
性能更好。
ConcurrentDictionary
： 替代
Dictionary
，多线程环境下安全地读写键值对。
ConcurrentQueue
： 替代
Queue
，实现线程安全的生产者-消费者队列。
ConcurrentBag
： 无序的元素集合，针对高并发添加和删除进行了优化，特别适合任务窃取（work-stealing）场景。
4.
Channel
(System.Threading.Channels)：这是一个相对较新的API（.NET Core 3.0+），提供了一种高效、类型安全的方式来进行生产者-消费者模式的数据传递。它类似于Go语言中的channel，可以在异步代码中实现线程间或任务间的数据流。它比传统的
Queue
+
Monitor
模式更简洁，更适合异步场景。
public async Task RunChannelExample(){ var channel = Channel.CreateUnbounded(); // 创建一个无界通道 // 生产者 _ = Task.Run(async () => { for (int i = 0; i < 10; i++) { await channel.Writer.WriteAsync(i); Console.WriteLine($"Produced: {i}"); await Task.Delay(100); } channel.Writer.Complete(); // 生产者完成，关闭通道 }); // 消费者 await foreach (var item in channel.Reader
以上就是C#的线程同步是什么？如何实现？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439322.html
微信扫一扫 
支付宝扫一扫 
