1. 为什么进程与线程是C#进阶的第一道分水岭刚入行那会儿我总觉得进程和线程是操作系统课上的概念跟写业务代码没多大关系。直到有一次做一个批量图片压缩的小工具单线程跑两千张图要将近四分钟界面全程卡死用户点一下按钮就以为程序崩了。后来硬着头皮把任务拆到线程池里时间压到四十多秒界面还能实时刷新进度条。那一刻我才真正意识到进程和线程不是书本上的名词而是决定程序“能不能用”和“好不好用”的底层开关。这篇笔记就是把我这些年踩过的坑、翻过的文档、写废过的代码重新梳理一遍。核心围绕C#里的**进程Process和线程Thread**两条主线展开讲清楚它们各自是什么、在什么场景下用、怎么用才不出事。涉及的知识点包括进程的启动与监控、线程的创建与生命周期、线程池的调度逻辑、Task与async/await的关系、并发安全与锁的取舍以及跨线程更新UI这类高频实战问题。适合已经能写C#基础语法、但一碰到多线程就心里发虚的开发者也适合想回头把底层概念补扎实的老手。我不会堆一堆API文档式的罗列而是按照“为什么这么设计—怎么落地—踩过什么坑”的顺序来讲。每个关键选择我都会解释背后的理由比如为什么现在更推荐Task而不是直接new Thread为什么lock不是万能的为什么有时候加锁反而更慢。这些判断不是拍脑袋来的而是从实际项目里一次次调试、一次次看dump文件总结出来的。2. 进程与线程的核心概念拆解2.1 用生活场景理解进程和线程的区别很多人背过“进程是资源分配的最小单位线程是CPU调度的最小单位”但背完还是不知道什么时候该用哪个。我习惯用一个类比进程就像一家独立的餐厅线程就是餐厅里的服务员。每家餐厅有自己的厨房、食材、收银台对应进程的独立内存空间、文件句柄、进程ID餐厅之间互不干扰一家倒闭了不影响隔壁。而服务员共享这家餐厅的所有资源可以同时接待不同桌的客人但如果有两个服务员同时去改同一张订单就会出乱子。在C#里你每启动一个exe操作系统就给它分配一个进程。这个进程默认带一个主线程也就是程序入口Main方法所在的那条执行流。你可以通过Process.Start()启动别的进程也可以通过Process.GetProcesses()查看当前系统里跑着哪些进程。而线程是在进程内部创建的一个进程可以有多个线程它们共享进程的内存空间所以通信成本低但正因为共享才需要格外小心数据竞争。注意进程之间默认是隔离的想通信得靠管道、共享内存、Socket这些手段线程之间默认是共享的想隔离反而要额外做工作。这个“默认行为”的差异是后面所有设计取舍的根源。2.2 前台线程与后台线程程序什么时候才肯退出C#里的线程分前台和后台这个区分特别容易被忽略但一旦搞错程序就会出现“窗口关了进程还在任务管理器里躺着”的尴尬。规则很简单只要还有一个前台线程在跑进程就不会退出所有前台线程结束后后台线程会被强制终止进程随之退出。主线程默认是前台线程。你用new Thread()创建出来的线程默认也是前台线程。而线程池里的线程默认是后台线程。所以如果你手动new了一个线程去跑一个死循环又忘了把它设为后台那用户关闭主窗口后进程依然会赖在系统里不走。var t new Thread(() { while (true) { /* 模拟后台轮询 */ } }); t.IsBackground true; // 关键的一行 t.Start();我踩过的坑是早期写一个日志上报模块用new Thread起了一个定时上报线程没设IsBackground结果测试同学反馈“软件关了但风扇还在转”。后来统一改成线程池或者Task这个问题就自然消失了因为线程池线程天生是后台线程。2.3 线程的生命周期与状态流转一个线程从创建到消亡会经历几个状态Unstarted、Running、WaitSleepJoin、Stopped等。很多人以为调用了Thread.Start()就立刻开始跑其实只是把线程置为可调度状态具体什么时候拿到CPU时间片由操作系统决定。同样Thread.Abort()在新版.NET里已经不被支持因为它强制终止线程可能导致资源泄漏和状态不一致正确做法是用CancellationToken做协作式取消。线程的状态流转里最值得关注的是阻塞。当线程调用Thread.Sleep()、等待锁、等待IO时它会进入阻塞状态让出CPU。这时候操作系统会调度别的线程上去跑。理解这一点很重要因为它解释了为什么“多线程能提高吞吐”——不是因为CPU变快了而是因为在一个线程等待IO的时候另一个线程可以继续干活把CPU的空闲时间利用起来。3. 进程操作在C#中的实战用法3.1 启动外部进程并捕获输出用C#调外部程序是很常见的需求比如调用某个命令行工具做格式转换。核心类是System.Diagnostics.Process。最基础的用法是Process.Start(notepad.exe)但实际项目里往往需要传参数、重定向输入输出、隐藏窗口、等待退出。var psi new ProcessStartInfo { FileName ffmpeg.exe, Arguments -i input.mp4 -vf scale1280:-1 output.mp4, UseShellExecute false, // 必须为false才能重定向 RedirectStandardOutput true, RedirectStandardError true, CreateNoWindow true }; using var proc new Process { StartInfo psi }; proc.Start(); string stdout proc.StandardOutput.ReadToEnd(); string stderr proc.StandardError.ReadToEnd(); proc.WaitForExit();这里有个经典死锁陷阱如果你先WaitForExit()再去读StandardOutput而子进程输出量很大填满了管道缓冲区子进程会阻塞在写操作上父进程又阻塞在等待退出上两边就僵住了。正确做法是先异步读取输出再等待退出或者用BeginOutputReadLine事件方式。实操心得UseShellExecute true时不能重定向false时才能拿到输出流。这个开关我见过太多人搞混记住“要抓输出就必须关掉Shell执行”就行。3.2 监控进程状态与优雅关闭启动进程之后经常需要知道它是不是还活着、占了多少内存、什么时候退出。Process类提供了HasExited、WorkingSet64、TotalProcessorTime这些属性。但要注意HasExited在进程已经退出后访问是安全的但如果进程还没启动就访问会抛异常所以最好配合EnableRaisingEvents和Exited事件来用。proc.EnableRaisingEvents true; proc.Exited (s, e) { Console.WriteLine($进程退出退出码{proc.ExitCode}); };关闭外部进程时直接Kill()是最后手段因为它不给对方清理的机会。更优雅的方式是先尝试CloseMainWindow()相当于用户点了窗口的关闭按钮给对方处理保存逻辑的时间。如果几秒后还没退出再Kill()兜底。这个“先礼后兵”的模式在需要调用第三方工具的场景里特别实用。3.3 进程间通信的几种常见手段两个进程要交换数据C#里常用的有这几种标准输入输出重定向适合父子进程命令行交互**命名管道NamedPipe**适合本机两个进程双向通信**内存映射文件MemoryMappedFile**适合大数据量共享Socket适合跨机器通信。选哪个取决于数据量、实时性和是否跨机。我做过一个本机数据同步的小工具两个进程需要频繁传结构化数据最后选了命名管道。原因是它基于流、支持双向、本机性能好而且.NET对NamedPipeServerStream和NamedPipeClientStream封装得比较顺手。内存映射文件虽然更快但同步读写位置的逻辑要自己管容易出错。4. 线程与线程池的落地细节4.1 new Thread、ThreadPool、Task到底怎么选这是被问得最多的问题。我的结论很直接绝大多数业务场景用Task需要精细控制线程优先级或长时间阻塞的用new Thread纯短小的并行计算可以考虑ThreadPool但Task本身就是建立在ThreadPool之上的所以优先Task。new Thread的开销不小创建一个线程默认要预留1MB左右的栈空间频繁创建销毁很浪费。线程池就是为了复用线程而生的它维护一组空闲线程有任务就派一个上去任务完了线程回到池子里待命。Task在此基础上又加了返回值、异常传播、延续ContinueWith、async/await支持写起来更舒服。// 不推荐每次调用都新建线程 new Thread(() DoWork()).Start(); // 推荐交给线程池调度 Task.Run(() DoWork()); // 有返回值 int result await Task.Run(() Compute());但Task也不是银弹。如果任务是长时间同步阻塞的比如一个死循环轮询它会一直占着线程池里的一个线程线程池线程数量有限占多了会导致其他任务排队。这种情况下要么用TaskCreationOptions.LongRunning提示调度器另起线程要么干脆用new Thread。4.2 线程池的调度逻辑与参数调优线程池默认的最小线程数跟CPU核心数相关最大线程数在.NET Core之后默认很大通常上千。但“最大”不等于“最优”线程太多上下文切换开销就上来了。线程池有个“爬坡”机制当任务排队而线程不够时它不会立刻创建新线程而是每隔一段时间大约500毫秒才新增一个。这个设计是为了避免瞬间创建大量线程但代价是突发高并发时任务会排队等待。如果你明确知道自己的场景需要更多并发线程可以用ThreadPool.SetMinThreads把最小线程数调高减少爬坡延迟。ThreadPool.GetMinThreads(out int worker, out int io); ThreadPool.SetMinThreads(worker * 2, io);注意调大最小线程数不是越多越好。我见过有人直接设成500结果内存占用飙升因为每个线程都有栈开销。一般建议根据实际压测结果来定从CPU核心数的2到4倍开始试。4.3 线程安全与锁的正确打开方式多线程最头疼的就是共享数据被同时修改。C#提供了lock、Monitor、Mutex、Semaphore、Interlocked、ReaderWriterLockSlim等一堆工具。新手最容易犯的错是“到处加lock”结果性能暴跌甚至死锁。lock的本质是Monitor的语法糖它保证同一时刻只有一个线程能进入临界区。但锁的粒度要尽量小只包住真正操作共享数据的那几行不要把耗时操作比如IO、网络请求放进锁里。另外锁对象要用私有的、引用类型的、不会被外部改动的字段千万别lock一个字符串或者this。private readonly object _syncRoot new object(); private int _counter; public void Increment() { lock (_syncRoot) { _counter; } }如果只是对一个整数做增减用Interlocked.Increment(ref _counter)比lock更轻量因为它是CPU级别的原子操作不需要锁的开销。读多写少的场景可以考虑ReaderWriterLockSlim允许多个读线程同时进入只在写的时候互斥。5. 并发编程中的高频问题与排查实录5.1 跨线程更新UI为什么会抛异常WinForms和WPF都要求UI控件只能在创建它的线程通常是主线程上访问。你在后台线程里直接改label.Text运行时就会抛InvalidOperationException。解决办法是让后台线程把更新操作“投递”回UI线程。WinForms里用Control.Invoke或BeginInvokelabel1.BeginInvoke(new Action(() { label1.Text 处理完成; }));WPF里用Dispatcher.Invokethis.Dispatcher.Invoke(() { textBlock.Text 处理完成; });Invoke是同步的会等UI线程执行完才返回BeginInvoke是异步的投递完就继续跑。后台线程里一般用BeginInvoke避免不必要的等待。这个坑我早期踩过无数次后来养成了习惯只要在非UI线程里碰到控件先想怎么切回去。5.2 死锁是怎么发生的怎么提前预防死锁的经典场景是“两个线程各自持有一把锁又都在等对方的锁”。比如线程A锁了对象1想锁对象2线程B锁了对象2想锁对象1两边就永远卡住了。预防死锁有几个实用原则按固定顺序获取锁、用超时机制Monitor.TryEnter带超时、避免嵌套锁、尽量用无锁数据结构。排查死锁时可以抓dump文件用调试工具看线程栈找到哪些线程卡在WaitOne或Enter上。生产环境里更实际的做法是加日志在获取锁前后打点一旦发现某个锁长时间没释放就能定位。5.3 常见并发问题速查表问题现象可能原因排查方向解决手段数据偶尔算错共享变量未加锁检查多线程写入点lock或Interlocked界面卡死主线程做耗时操作看主线程调用栈移到Task.Run进程关不掉前台线程未结束检查IsBackground设为后台或协作取消任务排队严重线程池线程被占满看线程池活跃数调大最小线程或改LongRunning死锁锁顺序不一致抓dump看线程栈统一锁顺序或加超时内存持续上涨线程未释放资源检查线程退出逻辑用CancellationToken这张表是我从实际项目里攒出来的基本覆盖了八成以上的并发问题。遇到问题先对号入座能省不少排查时间。5.4 协作式取消比Abort更安全的停止方式Thread.Abort()会强行给线程注入异常可能导致锁没释放、文件没关闭。正确做法是传递一个CancellationToken线程在循环里定期检查token.IsCancellationRequested发现取消请求就主动退出并清理资源。var cts new CancellationTokenSource(); Task.Run(() { while (!cts.Token.IsCancellationRequested) { // 干活 } // 清理资源 }, cts.Token); // 需要停止时 cts.Cancel();这个模式配合Task用起来很顺而且能跟async/await无缝衔接。我现在的习惯是任何可能长时间运行的任务入口就带一个CancellationToken参数哪怕暂时用不上也为以后留好退路。6. 从进程线程到异步编程的思维跃迁6.1 async/await并没有创建新线程很多人以为async方法会自动跑在新线程上其实不是。async/await是基于状态机的异步模型它解决的是“等待IO时不阻塞线程”的问题而不是“把活分给别的线程”。当你await一个网络请求时当前线程会返回线程池去处理别的任务等IO完成后再从线程池取一个线程继续执行后面的代码。整个过程可能压根没有新线程被创建。真正需要CPU密集计算时才用Task.Run把活丢到线程池。所以正确的组合是IO密集用async/awaitCPU密集用Task.Run。把这两个搞混就会出现“用async包了一个同步耗时方法结果还是卡”的情况。6.2 并行与并发的区别以及Parallel的适用场景并发是“多个任务交替推进”并行是“多个任务同时执行”。单核CPU上只能并发多核才能并行。C#的Parallel.For和Parallel.ForEach适合数据并行场景比如对一个数组里每个元素做独立计算。它会自动把工作切分到多个线程上。Parallel.For(0, 1000, i { results[i] HeavyCompute(i); });但Parallel不适合有共享状态写入的场景也不适合IO操作。而且它内部用的是线程池如果某个迭代阻塞了会拖累整体。用之前先想清楚任务之间是不是真的独立有没有共享资源如果答案不明确老老实实用Task逐个控制更稳妥。6.3 线程同步的替代思路不可变与消息传递加锁是解决共享状态竞争的手段但更好的思路是从设计上避免共享。比如用不可变对象record、ImmutableList每次修改都返回新实例这样多线程读同一个对象永远安全。再比如用消息队列或Channel在生产者消费者之间传递数据而不是让它们直接读写同一个集合。var channel Channel.CreateUnboundedint(); // 生产者 await channel.Writer.WriteAsync(42); // 消费者 await foreach (var item in channel.Reader.ReadAllAsync()) { Console.WriteLine(item); }System.Threading.Channels是我近几年最喜欢的并发工具之一它把生产者和消费者解耦内部处理好了同步写起来干净又不容易出错。如果你的场景是“一边产生数据一边处理数据”强烈建议试试Channel比手写锁加队列舒服太多。7. 一些压箱底的实操经验7.1 调试多线程问题的几个实用手段多线程bug最难的地方是“偶现”本地跑十次没事线上跑一万次崩一次。我的经验是先加日志再压测最后抓dump。日志要记录线程ID和时间戳这样能还原出问题发生时各线程的执行顺序。压测用工具模拟高并发把偶现问题变成必现。如果还定位不了就在崩溃时抓dump文件用调试器看所有线程的调用栈。另外Visual Studio的“并行堆栈”窗口和“线程”窗口在调试时很好用能直观看到每个线程卡在哪一行。条件断点也可以设置成“仅当某线程ID命中时触发”避免被其他线程干扰。7.2 线程数量的经验值到底开多少线程合适这个问题没有标准答案但有个经验公式可以参考CPU密集型任务线程数约等于CPU核心数IO密集型任务线程数可以远大于核心数因为线程大部分时间在等待。实际项目中我一般先用默认线程池跑观察CPU利用率和任务排队情况再决定要不要调整。如果CPU利用率一直上不去而任务又排长队说明线程不够或者被阻塞了如果CPU跑满但吞吐没提升说明线程太多上下文切换吃掉了收益。用性能计数器看Context Switches/sec和Thread Count能帮助判断。7.3 一个容易忽略的细节闭包捕获变量在循环里起线程或Task时如果闭包捕获了循环变量可能所有任务拿到的都是同一个值。这是C#里经典的坑。// 错误写法可能全部输出10 for (int i 0; i 10; i) { Task.Run(() Console.WriteLine(i)); } // 正确写法在循环体内复制一份 for (int i 0; i 10; i) { int local i; Task.Run(() Console.WriteLine(local)); }这个问题的根源是闭包捕获的是变量本身而不是值。在C# 5之后foreach的迭代变量已经被修正为每次迭代独立但for循环的变量仍然是共享的。写并发代码时凡是闭包里用到循环变量先想想是不是该复制一份。7.4 资源清理与异常处理不能偷懒后台线程里抛出的异常如果不处理可能导致进程直接崩溃。Task里的异常会被包装进AggregateException只有当你await或者访问Result时才会抛出。所以每个Task内部都要有try-catch把异常记录下来而不是让它悄悄溜走。Task.Run(() { try { // 干活 } catch (Exception ex) { // 记录日志别让异常逃逸 Logger.Error(ex); } });另外用到的CancellationTokenSource、SemaphoreSlim、ManualResetEventSlim这些实现了IDisposable的对象记得用using或者手动Dispose。资源泄漏在长时间运行的服务里是致命的跑几天内存就爆了。这套东西我前后折腾了好几年从最开始一知半解地new Thread到后来能根据场景熟练选型中间踩的坑基本都写在这了。进程和线程是C#并发编程的地基地基打牢了后面学async/await、Channel、并行LINQ都会顺很多。如果你现在还在“能跑就行”的阶段建议找个周末把这块系统过一遍后面省下的调试时间绝对值得。
1. 为什么进程与线程是C#进阶的第一道分水岭刚入行那会儿我总觉得进程和线程是操作系统课上的概念跟写业务代码没多大关系。直到有一次做一个批量图片压缩的小工具单线程跑两千张图要将近四分钟界面全程卡死用户点一下按钮就以为程序崩了。后来硬着头皮把任务拆到线程池里时间压到四十多秒界面还能实时刷新进度条。那一刻我才真正意识到进程和线程不是书本上的名词而是决定程序“能不能用”和“好不好用”的底层开关。这篇笔记就是把我这些年踩过的坑、翻过的文档、写废过的代码重新梳理一遍。核心围绕C#里的**进程Process和线程Thread**两条主线展开讲清楚它们各自是什么、在什么场景下用、怎么用才不出事。涉及的知识点包括进程的启动与监控、线程的创建与生命周期、线程池的调度逻辑、Task与async/await的关系、并发安全与锁的取舍以及跨线程更新UI这类高频实战问题。适合已经能写C#基础语法、但一碰到多线程就心里发虚的开发者也适合想回头把底层概念补扎实的老手。我不会堆一堆API文档式的罗列而是按照“为什么这么设计—怎么落地—踩过什么坑”的顺序来讲。每个关键选择我都会解释背后的理由比如为什么现在更推荐Task而不是直接new Thread为什么lock不是万能的为什么有时候加锁反而更慢。这些判断不是拍脑袋来的而是从实际项目里一次次调试、一次次看dump文件总结出来的。2. 进程与线程的核心概念拆解2.1 用生活场景理解进程和线程的区别很多人背过“进程是资源分配的最小单位线程是CPU调度的最小单位”但背完还是不知道什么时候该用哪个。我习惯用一个类比进程就像一家独立的餐厅线程就是餐厅里的服务员。每家餐厅有自己的厨房、食材、收银台对应进程的独立内存空间、文件句柄、进程ID餐厅之间互不干扰一家倒闭了不影响隔壁。而服务员共享这家餐厅的所有资源可以同时接待不同桌的客人但如果有两个服务员同时去改同一张订单就会出乱子。在C#里你每启动一个exe操作系统就给它分配一个进程。这个进程默认带一个主线程也就是程序入口Main方法所在的那条执行流。你可以通过Process.Start()启动别的进程也可以通过Process.GetProcesses()查看当前系统里跑着哪些进程。而线程是在进程内部创建的一个进程可以有多个线程它们共享进程的内存空间所以通信成本低但正因为共享才需要格外小心数据竞争。注意进程之间默认是隔离的想通信得靠管道、共享内存、Socket这些手段线程之间默认是共享的想隔离反而要额外做工作。这个“默认行为”的差异是后面所有设计取舍的根源。2.2 前台线程与后台线程程序什么时候才肯退出C#里的线程分前台和后台这个区分特别容易被忽略但一旦搞错程序就会出现“窗口关了进程还在任务管理器里躺着”的尴尬。规则很简单只要还有一个前台线程在跑进程就不会退出所有前台线程结束后后台线程会被强制终止进程随之退出。主线程默认是前台线程。你用new Thread()创建出来的线程默认也是前台线程。而线程池里的线程默认是后台线程。所以如果你手动new了一个线程去跑一个死循环又忘了把它设为后台那用户关闭主窗口后进程依然会赖在系统里不走。var t new Thread(() { while (true) { /* 模拟后台轮询 */ } }); t.IsBackground true; // 关键的一行 t.Start();我踩过的坑是早期写一个日志上报模块用new Thread起了一个定时上报线程没设IsBackground结果测试同学反馈“软件关了但风扇还在转”。后来统一改成线程池或者Task这个问题就自然消失了因为线程池线程天生是后台线程。2.3 线程的生命周期与状态流转一个线程从创建到消亡会经历几个状态Unstarted、Running、WaitSleepJoin、Stopped等。很多人以为调用了Thread.Start()就立刻开始跑其实只是把线程置为可调度状态具体什么时候拿到CPU时间片由操作系统决定。同样Thread.Abort()在新版.NET里已经不被支持因为它强制终止线程可能导致资源泄漏和状态不一致正确做法是用CancellationToken做协作式取消。线程的状态流转里最值得关注的是阻塞。当线程调用Thread.Sleep()、等待锁、等待IO时它会进入阻塞状态让出CPU。这时候操作系统会调度别的线程上去跑。理解这一点很重要因为它解释了为什么“多线程能提高吞吐”——不是因为CPU变快了而是因为在一个线程等待IO的时候另一个线程可以继续干活把CPU的空闲时间利用起来。3. 进程操作在C#中的实战用法3.1 启动外部进程并捕获输出用C#调外部程序是很常见的需求比如调用某个命令行工具做格式转换。核心类是System.Diagnostics.Process。最基础的用法是Process.Start(notepad.exe)但实际项目里往往需要传参数、重定向输入输出、隐藏窗口、等待退出。var psi new ProcessStartInfo { FileName ffmpeg.exe, Arguments -i input.mp4 -vf scale1280:-1 output.mp4, UseShellExecute false, // 必须为false才能重定向 RedirectStandardOutput true, RedirectStandardError true, CreateNoWindow true }; using var proc new Process { StartInfo psi }; proc.Start(); string stdout proc.StandardOutput.ReadToEnd(); string stderr proc.StandardError.ReadToEnd(); proc.WaitForExit();这里有个经典死锁陷阱如果你先WaitForExit()再去读StandardOutput而子进程输出量很大填满了管道缓冲区子进程会阻塞在写操作上父进程又阻塞在等待退出上两边就僵住了。正确做法是先异步读取输出再等待退出或者用BeginOutputReadLine事件方式。实操心得UseShellExecute true时不能重定向false时才能拿到输出流。这个开关我见过太多人搞混记住“要抓输出就必须关掉Shell执行”就行。3.2 监控进程状态与优雅关闭启动进程之后经常需要知道它是不是还活着、占了多少内存、什么时候退出。Process类提供了HasExited、WorkingSet64、TotalProcessorTime这些属性。但要注意HasExited在进程已经退出后访问是安全的但如果进程还没启动就访问会抛异常所以最好配合EnableRaisingEvents和Exited事件来用。proc.EnableRaisingEvents true; proc.Exited (s, e) { Console.WriteLine($进程退出退出码{proc.ExitCode}); };关闭外部进程时直接Kill()是最后手段因为它不给对方清理的机会。更优雅的方式是先尝试CloseMainWindow()相当于用户点了窗口的关闭按钮给对方处理保存逻辑的时间。如果几秒后还没退出再Kill()兜底。这个“先礼后兵”的模式在需要调用第三方工具的场景里特别实用。3.3 进程间通信的几种常见手段两个进程要交换数据C#里常用的有这几种标准输入输出重定向适合父子进程命令行交互**命名管道NamedPipe**适合本机两个进程双向通信**内存映射文件MemoryMappedFile**适合大数据量共享Socket适合跨机器通信。选哪个取决于数据量、实时性和是否跨机。我做过一个本机数据同步的小工具两个进程需要频繁传结构化数据最后选了命名管道。原因是它基于流、支持双向、本机性能好而且.NET对NamedPipeServerStream和NamedPipeClientStream封装得比较顺手。内存映射文件虽然更快但同步读写位置的逻辑要自己管容易出错。4. 线程与线程池的落地细节4.1 new Thread、ThreadPool、Task到底怎么选这是被问得最多的问题。我的结论很直接绝大多数业务场景用Task需要精细控制线程优先级或长时间阻塞的用new Thread纯短小的并行计算可以考虑ThreadPool但Task本身就是建立在ThreadPool之上的所以优先Task。new Thread的开销不小创建一个线程默认要预留1MB左右的栈空间频繁创建销毁很浪费。线程池就是为了复用线程而生的它维护一组空闲线程有任务就派一个上去任务完了线程回到池子里待命。Task在此基础上又加了返回值、异常传播、延续ContinueWith、async/await支持写起来更舒服。// 不推荐每次调用都新建线程 new Thread(() DoWork()).Start(); // 推荐交给线程池调度 Task.Run(() DoWork()); // 有返回值 int result await Task.Run(() Compute());但Task也不是银弹。如果任务是长时间同步阻塞的比如一个死循环轮询它会一直占着线程池里的一个线程线程池线程数量有限占多了会导致其他任务排队。这种情况下要么用TaskCreationOptions.LongRunning提示调度器另起线程要么干脆用new Thread。4.2 线程池的调度逻辑与参数调优线程池默认的最小线程数跟CPU核心数相关最大线程数在.NET Core之后默认很大通常上千。但“最大”不等于“最优”线程太多上下文切换开销就上来了。线程池有个“爬坡”机制当任务排队而线程不够时它不会立刻创建新线程而是每隔一段时间大约500毫秒才新增一个。这个设计是为了避免瞬间创建大量线程但代价是突发高并发时任务会排队等待。如果你明确知道自己的场景需要更多并发线程可以用ThreadPool.SetMinThreads把最小线程数调高减少爬坡延迟。ThreadPool.GetMinThreads(out int worker, out int io); ThreadPool.SetMinThreads(worker * 2, io);注意调大最小线程数不是越多越好。我见过有人直接设成500结果内存占用飙升因为每个线程都有栈开销。一般建议根据实际压测结果来定从CPU核心数的2到4倍开始试。4.3 线程安全与锁的正确打开方式多线程最头疼的就是共享数据被同时修改。C#提供了lock、Monitor、Mutex、Semaphore、Interlocked、ReaderWriterLockSlim等一堆工具。新手最容易犯的错是“到处加lock”结果性能暴跌甚至死锁。lock的本质是Monitor的语法糖它保证同一时刻只有一个线程能进入临界区。但锁的粒度要尽量小只包住真正操作共享数据的那几行不要把耗时操作比如IO、网络请求放进锁里。另外锁对象要用私有的、引用类型的、不会被外部改动的字段千万别lock一个字符串或者this。private readonly object _syncRoot new object(); private int _counter; public void Increment() { lock (_syncRoot) { _counter; } }如果只是对一个整数做增减用Interlocked.Increment(ref _counter)比lock更轻量因为它是CPU级别的原子操作不需要锁的开销。读多写少的场景可以考虑ReaderWriterLockSlim允许多个读线程同时进入只在写的时候互斥。5. 并发编程中的高频问题与排查实录5.1 跨线程更新UI为什么会抛异常WinForms和WPF都要求UI控件只能在创建它的线程通常是主线程上访问。你在后台线程里直接改label.Text运行时就会抛InvalidOperationException。解决办法是让后台线程把更新操作“投递”回UI线程。WinForms里用Control.Invoke或BeginInvokelabel1.BeginInvoke(new Action(() { label1.Text 处理完成; }));WPF里用Dispatcher.Invokethis.Dispatcher.Invoke(() { textBlock.Text 处理完成; });Invoke是同步的会等UI线程执行完才返回BeginInvoke是异步的投递完就继续跑。后台线程里一般用BeginInvoke避免不必要的等待。这个坑我早期踩过无数次后来养成了习惯只要在非UI线程里碰到控件先想怎么切回去。5.2 死锁是怎么发生的怎么提前预防死锁的经典场景是“两个线程各自持有一把锁又都在等对方的锁”。比如线程A锁了对象1想锁对象2线程B锁了对象2想锁对象1两边就永远卡住了。预防死锁有几个实用原则按固定顺序获取锁、用超时机制Monitor.TryEnter带超时、避免嵌套锁、尽量用无锁数据结构。排查死锁时可以抓dump文件用调试工具看线程栈找到哪些线程卡在WaitOne或Enter上。生产环境里更实际的做法是加日志在获取锁前后打点一旦发现某个锁长时间没释放就能定位。5.3 常见并发问题速查表问题现象可能原因排查方向解决手段数据偶尔算错共享变量未加锁检查多线程写入点lock或Interlocked界面卡死主线程做耗时操作看主线程调用栈移到Task.Run进程关不掉前台线程未结束检查IsBackground设为后台或协作取消任务排队严重线程池线程被占满看线程池活跃数调大最小线程或改LongRunning死锁锁顺序不一致抓dump看线程栈统一锁顺序或加超时内存持续上涨线程未释放资源检查线程退出逻辑用CancellationToken这张表是我从实际项目里攒出来的基本覆盖了八成以上的并发问题。遇到问题先对号入座能省不少排查时间。5.4 协作式取消比Abort更安全的停止方式Thread.Abort()会强行给线程注入异常可能导致锁没释放、文件没关闭。正确做法是传递一个CancellationToken线程在循环里定期检查token.IsCancellationRequested发现取消请求就主动退出并清理资源。var cts new CancellationTokenSource(); Task.Run(() { while (!cts.Token.IsCancellationRequested) { // 干活 } // 清理资源 }, cts.Token); // 需要停止时 cts.Cancel();这个模式配合Task用起来很顺而且能跟async/await无缝衔接。我现在的习惯是任何可能长时间运行的任务入口就带一个CancellationToken参数哪怕暂时用不上也为以后留好退路。6. 从进程线程到异步编程的思维跃迁6.1 async/await并没有创建新线程很多人以为async方法会自动跑在新线程上其实不是。async/await是基于状态机的异步模型它解决的是“等待IO时不阻塞线程”的问题而不是“把活分给别的线程”。当你await一个网络请求时当前线程会返回线程池去处理别的任务等IO完成后再从线程池取一个线程继续执行后面的代码。整个过程可能压根没有新线程被创建。真正需要CPU密集计算时才用Task.Run把活丢到线程池。所以正确的组合是IO密集用async/awaitCPU密集用Task.Run。把这两个搞混就会出现“用async包了一个同步耗时方法结果还是卡”的情况。6.2 并行与并发的区别以及Parallel的适用场景并发是“多个任务交替推进”并行是“多个任务同时执行”。单核CPU上只能并发多核才能并行。C#的Parallel.For和Parallel.ForEach适合数据并行场景比如对一个数组里每个元素做独立计算。它会自动把工作切分到多个线程上。Parallel.For(0, 1000, i { results[i] HeavyCompute(i); });但Parallel不适合有共享状态写入的场景也不适合IO操作。而且它内部用的是线程池如果某个迭代阻塞了会拖累整体。用之前先想清楚任务之间是不是真的独立有没有共享资源如果答案不明确老老实实用Task逐个控制更稳妥。6.3 线程同步的替代思路不可变与消息传递加锁是解决共享状态竞争的手段但更好的思路是从设计上避免共享。比如用不可变对象record、ImmutableList每次修改都返回新实例这样多线程读同一个对象永远安全。再比如用消息队列或Channel在生产者消费者之间传递数据而不是让它们直接读写同一个集合。var channel Channel.CreateUnboundedint(); // 生产者 await channel.Writer.WriteAsync(42); // 消费者 await foreach (var item in channel.Reader.ReadAllAsync()) { Console.WriteLine(item); }System.Threading.Channels是我近几年最喜欢的并发工具之一它把生产者和消费者解耦内部处理好了同步写起来干净又不容易出错。如果你的场景是“一边产生数据一边处理数据”强烈建议试试Channel比手写锁加队列舒服太多。7. 一些压箱底的实操经验7.1 调试多线程问题的几个实用手段多线程bug最难的地方是“偶现”本地跑十次没事线上跑一万次崩一次。我的经验是先加日志再压测最后抓dump。日志要记录线程ID和时间戳这样能还原出问题发生时各线程的执行顺序。压测用工具模拟高并发把偶现问题变成必现。如果还定位不了就在崩溃时抓dump文件用调试器看所有线程的调用栈。另外Visual Studio的“并行堆栈”窗口和“线程”窗口在调试时很好用能直观看到每个线程卡在哪一行。条件断点也可以设置成“仅当某线程ID命中时触发”避免被其他线程干扰。7.2 线程数量的经验值到底开多少线程合适这个问题没有标准答案但有个经验公式可以参考CPU密集型任务线程数约等于CPU核心数IO密集型任务线程数可以远大于核心数因为线程大部分时间在等待。实际项目中我一般先用默认线程池跑观察CPU利用率和任务排队情况再决定要不要调整。如果CPU利用率一直上不去而任务又排长队说明线程不够或者被阻塞了如果CPU跑满但吞吐没提升说明线程太多上下文切换吃掉了收益。用性能计数器看Context Switches/sec和Thread Count能帮助判断。7.3 一个容易忽略的细节闭包捕获变量在循环里起线程或Task时如果闭包捕获了循环变量可能所有任务拿到的都是同一个值。这是C#里经典的坑。// 错误写法可能全部输出10 for (int i 0; i 10; i) { Task.Run(() Console.WriteLine(i)); } // 正确写法在循环体内复制一份 for (int i 0; i 10; i) { int local i; Task.Run(() Console.WriteLine(local)); }这个问题的根源是闭包捕获的是变量本身而不是值。在C# 5之后foreach的迭代变量已经被修正为每次迭代独立但for循环的变量仍然是共享的。写并发代码时凡是闭包里用到循环变量先想想是不是该复制一份。7.4 资源清理与异常处理不能偷懒后台线程里抛出的异常如果不处理可能导致进程直接崩溃。Task里的异常会被包装进AggregateException只有当你await或者访问Result时才会抛出。所以每个Task内部都要有try-catch把异常记录下来而不是让它悄悄溜走。Task.Run(() { try { // 干活 } catch (Exception ex) { // 记录日志别让异常逃逸 Logger.Error(ex); } });另外用到的CancellationTokenSource、SemaphoreSlim、ManualResetEventSlim这些实现了IDisposable的对象记得用using或者手动Dispose。资源泄漏在长时间运行的服务里是致命的跑几天内存就爆了。这套东西我前后折腾了好几年从最开始一知半解地new Thread到后来能根据场景熟练选型中间踩的坑基本都写在这了。进程和线程是C#并发编程的地基地基打牢了后面学async/await、Channel、并行LINQ都会顺很多。如果你现在还在“能跑就行”的阶段建议找个周末把这块系统过一遍后面省下的调试时间绝对值得。
