1. 为什么多线程这件事光看文档根本不够用刚入行那会儿我对多线程的理解基本停留在“开个Thread就能跑”的阶段。直到有一次做一个数据采集的小工具单线程跑一批任务要四十多秒我心想这还不简单循环里直接起线程不就完了。结果程序跑起来CPU直接飙满界面卡死数据还丢了几条。排查了大半天才发现线程开得太随意既没有控制并发数量也没有做任何同步多个线程同时往一个List里塞数据不丢才怪。这件事让我意识到C#的多线程远不是“会开线程”这么简单。它涉及线程的生命周期管理、并发控制、同步机制、异常处理、资源回收等一系列问题。你写的代码在单线程下跑一百遍都没事放到多线程环境里可能第一遍就崩。而且这类问题往往不是必现的可能跑十次才出一次排查起来极其痛苦。这篇内容适合哪些人看如果你已经写过一些C#代码对基本语法没问题但一碰到多线程就心里没底不知道怎么下手、不知道怎么排查问题那这篇就是写给你的。我不会只给你贴API文档而是把每个关键决策背后的逻辑讲清楚把我在实际项目里踩过的坑和总结出来的经验都摊开来说。从最基础的Thread到Task从lock到CancellationToken从线程安全到死锁排查尽量做到你看完就能上手上手就不容易翻车。2. 先把线程和进程的关系理清楚不然后面全是糊涂账2.1 进程是厂房线程是流水线很多教程一上来就讲怎么创建线程但我觉得有必要先把进程和线程的关系说透。打个比方进程就像一座厂房厂房里有独立的电力系统、供水系统、仓储空间。线程就像厂房里的流水线多条流水线共享厂房的电力、水源和仓库但每条流水线有自己的工位和操作台。映射到操作系统层面进程拥有独立的内存地址空间、文件句柄、网络端口等资源。线程共享进程的这些资源但每个线程有自己的栈空间用来存局部变量和方法调用信息和寄存器状态用来记录当前执行到哪了。这个区别非常关键因为它直接决定了多线程编程中哪些东西需要特别小心。共享的资源意味着多个线程可以同时读写同一块内存这就带来了数据竞争的问题。而独立的栈空间意味着局部变量天然是线程安全的因为每个线程都有自己的副本。理解这一点你就能明白为什么有时候加锁有时候不用加锁。2.2 前台线程和后台线程的区别别等程序关不掉才后悔C#里的线程分前台和后台两种。默认用new Thread()创建出来的是前台线程前台线程没结束整个进程就不会退出。后台线程则不同只要所有前台线程都结束了后台线程会被强制终止进程直接退出。我见过有同事写了一个定时轮询的线程忘了设成后台结果程序主窗口关了进程还在任务管理器里挂着用户以为程序没关干净。设置方法很简单var thread new Thread(DoWork); thread.IsBackground true; // 设为后台线程 thread.Start();但这里有个坑要注意后台线程被强制终止时它正在执行的代码会被直接掐断finally块不保证执行。如果你的线程里有需要确保释放的资源比如写文件、释放锁就不能依赖后台线程的自动终止得自己做好清理逻辑。2.3 线程的生命周期不是你想的那样线性一个线程从创建到结束大致经历这几个阶段未启动、就绪、运行、阻塞、终止。但实际操作中这些状态之间的转换并不是你能完全控制的。比如你调用了thread.Start()线程并不是立刻就开始执行而是进入就绪队列等待CPU调度。你调用thread.Join()当前线程会阻塞等待目标线程结束但等待多久是不确定的。还有一个容易忽略的点线程结束后不能重新启动。一个Thread对象只能Start一次想再跑就得new一个新的。这个限制在设计重试逻辑的时候要特别注意。3. Thread、ThreadPool、Task到底该选哪个3.1 Thread控制力最强但代价也最大System.Threading.Thread是最原始的线程操作方式给你最细粒度的控制。你可以设置线程优先级、给线程命名调试时非常有用、控制线程是前台还是后台。但它的代价是每创建一个Thread操作系统就要分配大约1MB的栈空间创建和销毁的开销都不小。如果你的场景是长时间运行的后台任务比如一个一直循环处理消息队列的消费者用Thread是合理的。但如果是大量短小的任务比如并行处理一百个独立的计算每个都起一个Thread就太浪费了。// 适合长时间运行的后台任务 var worker new Thread(() { while (!cancellationToken.IsCancellationRequested) { // 持续处理任务 ProcessNextItem(); } }); worker.IsBackground true; worker.Name MessageProcessor; worker.Start();3.2 ThreadPool省资源但别拿它跑长任务线程池的思路是复用线程。它维护一组空闲线程你有任务就丢进去池子里有空闲线程就拿来用用完还回去。这样就避免了频繁创建和销毁线程的开销。ThreadPool.QueueUserWorkItem()是最基本的用法。但线程池有个重要的限制池子里的线程数量是有限的默认跟CPU核心数相关。如果你往池子里丢了大量长时间运行的任务池子里的线程全被占满后续的任务就只能排队等着。更严重的是如果这些长任务之间还有依赖关系就可能出现死锁——A任务在等B任务的结果但B任务在队列里排着因为没有空闲线程来执行它。经验法则线程池适合执行短小的、CPU密集型的任务。超过几百毫秒的任务建议考虑其他方案。3.3 Task现代C#多线程的首选Task是.NET 4.0引入的到了.NET 4.5配合async/await基本上成了C#异步编程的标准方案。Task底层默认使用线程池但它比直接操作ThreadPool方便太多支持返回值、支持异常传播、支持取消、支持延续ContinueWith、支持组合WhenAll/WhenAny。// 启动一个带返回值的Task Taskint task Task.Run(() { // 模拟耗时计算 Thread.Sleep(1000); return 42; }); // 等待结果 int result await task; Console.WriteLine($结果是{result});Task的异常处理也设计得很好。如果Task内部抛了异常这个异常会被捕获并存储在Task对象里当你await或者访问Task.Result时异常会被重新抛出。如果一直没人访问Task被GC回收时也不会导致进程崩溃这点和Thread不同Thread里未处理的异常会直接终止进程。3.4 三者的选择对照表维度ThreadThreadPoolTask创建开销高约1MB栈低复用线程低底层用池控制粒度最细较粗灵活返回值不支持不支持支持异常传播直接崩溃直接崩溃可捕获取消支持需手动实现需手动实现原生支持适用场景长驻后台任务短小CPU任务绝大多数场景我个人的建议是新项目一律优先用Task除非你有非常明确的理由需要用Thread比如需要设置线程优先级或者需要STA线程来做COM互操作。ThreadPool直接用的场景也越来越少了Task基本能覆盖它的所有用例而且更好用。4. 线程安全这件事不加锁迟早要还债4.1 一个经典的计数器翻车案例先看一段看起来毫无问题的代码private int _counter 0; public void Increment() { _counter; }单线程下这段代码跑一万次_counter就是一万。但如果你开十个线程每个线程调一千次最后的结果大概率小于一万。为什么因为_counter不是原子操作它实际上分三步读取当前值、加一、写回。两个线程可能同时读到同一个值各自加一后写回结果只增加了一次。这就是典型的数据竞争。修复方法是用Interlocked.Increment(ref _counter)它保证加一操作是原子的。或者用lock把整个操作包起来。4.2 lock的本质和常见误用lock是C#里最常用的同步手段它的本质是Monitor的语法糖。lock(obj) { ... }会在进入代码块时获取obj的锁退出时释放。同一时刻只有一个线程能持有这个锁其他线程会阻塞等待。但lock有几个常见的误用第一个坑锁的对象选错了。锁值类型比如lock(1)是不行的因为值类型会被装箱成不同的对象每次锁的都不是同一个东西。锁字符串更危险因为字符串驻留机制可能导致不同地方的代码锁到同一个字符串对象造成意外的阻塞。正确的做法是定义一个专门的私有object字段作为锁对象private readonly object _lockObj new object(); public void SafeMethod() { lock (_lockObj) { // 临界区代码 } }第二个坑锁的粒度太大。有些人为了省事把整个方法体都包在lock里结果所有线程都串行执行多线程变成了单线程性能还不如不加。锁的范围应该尽可能小只包住真正需要保护的共享资源操作。第三个坑在锁里做耗时操作。比如在lock块里做IO操作、网络请求、调用外部服务这会导致其他线程长时间阻塞。锁里应该只做内存操作耗时的事情放到锁外面做。4.3 除了lock还有哪些同步工具C#提供的同步原语远不止lock一个不同的场景适合不同的工具Monitorlock的底层实现比lock更灵活支持TryEnter带超时的等待。Mutex跨进程的互斥锁比Monitor重但可以跨进程同步。Semaphore/SemaphoreSlim信号量控制同时访问某个资源的线程数量。SemaphoreSlim更轻量推荐优先使用。ReaderWriterLockSlim读写锁允许多个线程同时读但写的时候独占。适合读多写少的场景。AutoResetEvent/ManualResetEvent线程间信号通知一个线程等信号另一个线程发信号。// SemaphoreSlim示例限制同时最多3个线程访问 private static readonly SemaphoreSlim _semaphore new SemaphoreSlim(3); public async Task AccessResourceAsync() { await _semaphore.WaitAsync(); try { // 最多3个线程能同时到这里 await DoWorkAsync(); } finally { _semaphore.Release(); } }选择哪种同步工具核心看你的场景是互斥还是限流是读多写少还是读写均衡是否需要跨进程是否需要异步等待把这些想清楚了工具自然就选出来了。5. 死锁不是运气不好是你亲手埋的雷5.1 死锁的四个必要条件死锁这件事学术上有一套完整的理论。Coffman在1971年提出了死锁的四个必要条件互斥、持有并等待、不可抢占、循环等待。四个条件同时满足才会死锁破坏其中任何一个就能避免。但在实际写代码的时候你不需要背这些理论。你只需要记住一个最实用的原则如果你需要获取多个锁确保所有线程以相同的顺序获取。5.2 一个真实的死锁排查过程我之前遇到过一个死锁现象是程序跑着跑着就卡住了不报错、不崩溃就是不动了。用调试器attach上去一看两个线程互相等着对方释放锁。线程A持有锁X等待锁Y。线程B持有锁Y等待锁X。典型的AB-BA死锁。排查这种问题的步骤用Visual Studio的“线程”窗口查看所有线程的调用栈。找到处于WaitSleepJoin状态的线程。看它们在等什么锁谁持有那个锁。画出等待关系图找到环。修复方法很简单统一加锁顺序。比如规定所有地方都先锁X再锁Y就不会出现互相等待的情况。5.3 用超时机制给锁加一道保险即使你非常小心也不能保证永远不会死锁。所以一个防御性的做法是给锁等待设置超时。private readonly object _lockA new object(); private readonly object _lockB new object(); public bool TryDoSomething() { // 尝试获取锁A最多等500毫秒 if (!Monitor.TryEnter(_lockA, 500)) return false; try { // 尝试获取锁B最多等500毫秒 if (!Monitor.TryEnter(_lockB, 500)) return false; try { // 执行需要同时持有两把锁的操作 return true; } finally { Monitor.Exit(_lockB); } } finally { Monitor.Exit(_lockA); } }这样即使出现死锁倾向也会在超时后返回失败而不是永久卡死。当然超时后你需要有相应的降级处理逻辑不能直接忽略。6. 取消、异常和进度多线程编程的三个老大难6.1 CancellationToken不是可选项是必选项很多人在写多线程代码的时候不考虑取消觉得任务跑完就行了。但实际项目中用户可能中途关闭窗口、可能切换到别的页面、可能网络断了需要重试。如果你的后台任务不能取消就会变成僵尸任务白白消耗资源。CancellationToken的使用模式很固定public async Task LongRunningOperationAsync(CancellationToken cancellationToken) { for (int i 0; i 1000; i) { // 在每个循环迭代检查是否取消 cancellationToken.ThrowIfCancellationRequested(); await ProcessItemAsync(i, cancellationToken); } }调用方通过CancellationTokenSource来控制取消var cts new CancellationTokenSource(); // 启动任务 var task LongRunningOperationAsync(cts.Token); // 需要取消时 cts.Cancel(); // 等待任务结束会抛OperationCanceledException try { await task; } catch (OperationCanceledException) { // 任务被正常取消 }注意几个细节ThrowIfCancellationRequested会抛异常所以要在合适的地方调用确保异常能被正确捕获。另外取消不是即时的任务可能在收到取消信号后还需要一些时间来做清理工作。6.2 多线程里的异常处理跟单线程完全不一样单线程里异常沿着调用栈往上抛你在哪里catch就在哪里处理。但多线程里子线程抛出的异常不会自动传播到主线程。如果你在子线程里抛了异常而没处理在.NET中默认会导致整个进程崩溃。用Task的话情况好一些异常会被存储在Task对象里等你await的时候重新抛出。但如果你用的是Task.Run然后忘了await或者用了ContinueWith但没处理异常异常就可能被吞掉。// 错误做法异常被吞掉 Task.Run(() { throw new Exception(出错了); }); // 正确做法await会重新抛出异常 try { await Task.Run(() { throw new Exception(出错了); }); } catch (Exception ex) { Console.WriteLine($捕获到异常{ex.Message}); }如果同时跑多个Task用Task.WhenAll等待所有任务完成它会等所有任务结束后抛出一个AggregateException里面包含所有任务抛出的异常。你可以遍历InnerExceptions来逐个处理。6.3 进度报告用IProgress别自己造轮子后台任务需要向UI报告进度是很常见的需求。但UI控件只能在UI线程上更新后台线程直接操作UI控件会抛异常。.NET提供了IProgressT接口来优雅地解决这个问题// UI线程创建Progress对象 var progress new Progressint(percent { progressBar.Value percent; // 自动回到UI线程执行 }); // 后台任务报告进度 await Task.Run(() { for (int i 0; i 100; i) { Thread.Sleep(50); progress.Report(i); } });ProgressT的构造函数会捕获当前线程的SynchronizationContext在Report被调用时自动切换回原来的上下文。在UI程序里就是回到UI线程在控制台程序里就是线程池线程。这个设计非常巧妙省去了手动Invoke的麻烦。7. 并发集合和PLINQ该用现成的就别自己造7.1 为什么List不是线程安全的ListT内部用一个数组存储元素还有一个_size字段记录当前元素个数。当你调用Add方法时它会检查容量、可能扩容、写入元素、更新_size。这一系列操作在多线程环境下没有任何保护两个线程同时Add就可能覆盖对方的数据或者_size更新丢失。DictionaryK,V更危险它在扩容的时候会重建整个哈希表如果这时候另一个线程在读取可能读到不一致的中间状态甚至进入死循环。7.2 Concurrent集合的正确打开方式.NET在System.Collections.Concurrent命名空间下提供了一组线程安全的集合集合类型适用场景特点ConcurrentDictionary高并发键值对读写无锁读取细粒度锁写入ConcurrentQueue生产者-消费者队列无锁实现FIFOConcurrentStack后进先出场景无锁实现LIFOConcurrentBag无序集合每个线程独立存储减少竞争BlockingCollection有界阻塞队列支持阻塞等待和容量限制这些集合内部用了很多无锁编程的技巧性能比你自己用lock包一个普通集合要好得多。能用现成的就用现成的别自己造轮子。// 生产者-消费者模式的标准写法 var queue new BlockingCollectionstring(boundedCapacity: 100); // 生产者 var producer Task.Run(() { for (int i 0; i 1000; i) { queue.Add($item-{i}); } queue.CompleteAdding(); // 标记不再添加 }); // 消费者 var consumer Task.Run(() { foreach (var item in queue.GetConsumingEnumerable()) { ProcessItem(item); } }); await Task.WhenAll(producer, consumer);7.3 PLINQ一行代码实现数据并行如果你有一个大的集合需要做相同的处理PLINQ可以让你几乎不改代码就实现并行化// 串行版本 var results data.Where(x x.IsValid) .Select(x ExpensiveTransform(x)) .ToList(); // 并行版本加一个AsParallel就行 var results data.AsParallel() .Where(x x.IsValid) .Select(x ExpensiveTransform(x)) .ToList();但PLINQ不是万能的。如果每个元素的处理很快并行化的调度开销可能比省下来的时间还多。另外PLINQ不保证元素的处理顺序如果顺序重要需要用AsOrdered()。还有PLINQ内部的异常也会被包装成AggregateException。我的一般建议是数据量小于一万条、单条处理时间小于一毫秒的场景没必要用PLINQ。数据量大且单条处理耗时的场景PLINQ能带来明显的加速。8. 调试多线程代码的实战技巧8.1 给线程起名字调试时能救命线程默认的名字是null在调试器的线程窗口里只能看到线程ID根本分不清谁是谁。养成给关键线程起名字的习惯var thread new Thread(DoWork); thread.Name DataProcessor; // 调试时一眼就能认出来Task的话可以用Task.CurrentId来区分但更推荐在日志里打上任务标识。8.2 用条件断点和并行堆栈定位问题Visual Studio的并行堆栈窗口调试 - 窗口 - 并行堆栈可以图形化地展示所有线程的调用栈和它们之间的等待关系。排查死锁的时候特别好用。条件断点也很实用。比如你怀疑某个变量在特定值的时候出问题可以设置条件断点只有满足条件时才断下来避免频繁手动继续。8.3 日志是多线程调试的生命线多线程的问题往往难以复现所以日志至关重要。但普通的日志库在多线程下可能有问题比如写入冲突导致日志丢失。建议用支持线程安全的日志库并且在日志里记录线程ID和时间戳Console.WriteLine($[Thread-{Thread.CurrentThread.ManagedThreadId}] $[{DateTime.Now:HH:mm:ss.fff}] 开始处理任务);这样出问题的时候你可以根据日志还原出各个线程的执行顺序和交错情况。9. 几个我踩过的坑和对应的解决方案9.1 在lock里await导致的死锁这是一个非常隐蔽的坑。看这段代码// 危险代码 public async Task DoSomethingAsync() { lock (_lockObj) { await SomeAsyncOperation(); // 在lock里await } }C#的lock块里是不能await的编译器会报错但如果你用Monitor.Enter/Exit手动加锁就可以绕过编译检查写出在持有锁的时候await的代码。这非常危险因为await会让出当前线程其他线程可能趁机获取锁然后当你await结束后想继续执行时发现自己还在等锁而死锁就形成了。解决方案永远不要在持有锁的时候做异步等待。如果确实需要用SemaphoreSlim的WaitAsyncprivate readonly SemaphoreSlim _semaphore new SemaphoreSlim(1, 1); public async Task DoSomethingAsync() { await _semaphore.WaitAsync(); try { await SomeAsyncOperation(); } finally { _semaphore.Release(); } }9.2 Task.Run嵌套Task.Run的性能陷阱有些人写异步代码的时候习惯性地到处包Task.Run// 不必要的嵌套 await Task.Run(() Task.Run(() DoWork()));这会导致线程池里多消耗一个线程来等待另一个线程纯属浪费。Task.Run应该只在需要把同步的CPU密集型工作放到后台线程时使用。如果方法本身就是异步的返回Task直接await就行不需要再包一层Task.Run。9.3 忘记配置await的上下文导致UI卡顿在UI程序里await默认会回到UI线程继续执行。如果你在UI线程上调用了SomeAsyncMethod().Result或者.Wait()就会阻塞UI线程而异步方法完成后又想回到UI线程继续但UI线程被阻塞了回不来死锁就发生了。解决方案在库代码里用ConfigureAwait(false)表示不需要回到原来的上下文// 库代码中推荐 var data await httpClient.GetStringAsync(url).ConfigureAwait(false);在UI事件处理函数里则不需要加因为你就是想回到UI线程更新控件。10. 从单线程到多线程的渐进式改造思路如果你手上有一个单线程的程序想改成多线程来提升性能我建议不要一上来就大改。按这个思路来第一步先找出性能瓶颈在哪里。用性能分析工具跑一遍看看时间花在什么地方。如果瓶颈在IO等待那多线程确实能帮上忙。如果瓶颈在CPU计算那要看能不能并行化。第二步把可以独立执行的任务识别出来。哪些任务之间没有依赖关系哪些任务可以同时执行把这些任务抽出来设计成独立的单元。第三步从最简单的并行开始。比如用Parallel.For或者Task.WhenAll把独立的任务并行跑起来先看看效果和有没有问题。第四步逐步引入同步机制。当发现数据竞争的时候再针对性地加锁或用并发集合而不是一开始就到处加锁。第五步加上取消和异常处理。这是生产环境必须的但在原型阶段可以先放一放。这个渐进式的思路能让你在每一步都有可运行的版本出问题也容易定位是哪个改动引入的。最怕的就是一次性大改改完一堆bug根本不知道从哪查起。11. 一些值得记住的实用原则写了这么多最后分享几条我在实际项目中总结出来的原则不一定全面但都是真金白银换来的能不共享就不共享。多线程问题的根源就是共享状态。如果每个线程能用自己的数据就不用加锁不用同步问题少一大半。局部变量天然线程安全尽量用局部变量。不可变对象是最好的朋友。如果一个对象创建后就不会变那多线程随便读都没问题。C#的record类型、string、以及自己写的不可变类在多线程环境里用起来最省心。加锁的范围越小越好。锁的粒度直接决定了并发性能。只锁必要的代码锁里只做内存操作。优先用高层抽象。Task比Thread好并发集合比手动加锁好IProgress比手动Invoke好。高层抽象经过了大量测试和优化比你自己写的更可靠。测试的时候多跑几遍。多线程的bug往往不是必现的跑一遍没问题不代表真的没问题。有条件的话用压力测试跑个几百遍或者用专门的并发测试工具。日志要打够但别太多。日志是排查问题的关键但日志本身也有性能开销而且多线程下日志写入可能成为新的竞争点。关键路径打日志非关键路径用条件编译控制。多线程编程这件事理论看再多不动手写几遍是学不会的。建议你从一个小项目开始比如写一个并发的文件下载器或者一个多线程的排序对比工具把上面说的这些概念都实践一遍。遇到问题不要怕每个坑踩过一次下次就知道怎么绕了。