1. 为什么需要多线程 —— 从一次线上事故说起大概两年前我在某公司做一次接口性能优化。那个接口本身功能不复杂就是从多个数据源拉取信息汇总后返回给前端。问题在于它是同步执行的——先查订单库再查库存库再查物流信息最后还要调一次第三方接口。单次请求耗时平均接近2秒。平时流量不大还扛得住一到大促流量上来线程池被占满后面所有请求排长队超时率肉眼可见地往上飙。这个场景在业务开发中太典型了。单线程最大的问题不是慢而是资源利用率低。等数据库返回的时候CPU实际上是空闲的等第三方接口响应的时候数据库连接也已经释放了。能不能做到等A的时候顺便把B做了这就是多线程要解决的核心问题。C#开发者走到一定阶段几乎都会遇到这几个坎界面卡死、接口超时、日志里出现诡异的并发异常。这些问题的解药或多或少的都指向多线程。但这恰恰是很多自学者的痛点——网上讲多线程的文章要么太浅只贴一堆代码没说为什么要么太深一上来就是锁、内存模型、指令重排直接把初学者劝退了。我计划用几篇文章把C#多线程这条路完整走一遍。第一篇专注基础概念把线程、线程池、任务、异步的区别讲清楚扫清术语上的障碍。后续会逐步深入到锁、并发集合、异步编程底层原理、常见的性能陷阱等等。这篇面向的是有C#语法基础但没系统学过并发的读者看完不会直接成为专家但至少能读懂大部分多线程代码并且敢在自己的项目里动手写了。2. 核心概念先理清楚线程、进程、线程池与任务2.1 进程和线程到底是什么关系很多初学者把进程和线程混为一谈。打个比方进程就像一家独立的公司有自己的办公场地独立的内存空间、自己的员工名册句柄表、自己的规章制度资源配额。而线程就是这家公司里的员工多个员工共享同一个办公场地一起读写同一块白板共享内存但各自的办公桌栈空间是独立的。在C#里启动一个.NET程序操作系统会给你创建一个进程。进程内部默认有一个主线程就是执行Main方法那个。创建额外的线程相当于在这个公司里多招了几个员工它们可以并行干活。关键点在于内存空间。进程之间内存是隔离的——进程A改了自己的变量进程B完全无感知但同一进程内的多个线程共享堆内存这意味着线程A创建的某个对象线程B可以直接访问。共享带来效率也带来麻烦——两个线程同时改同一个变量结果就可能错乱。这是后面所有并发问题的根源。2.2 线程是个昂贵资源别自己乱newC#里最基础的创建线程方式是new Thread(...)。很多教材会教你写出这样的代码Thread thread new Thread(() Console.WriteLine(我是子线程)); thread.Start();但实际生产中直接手动创建线程是非常不推荐的。原因很现实线程的创建和销毁是有成本的。每次创建线程操作系统要分配内核对象、初始化栈空间走一遍完整的初始化流程这些开销都实打实花在毫秒级别高频场景下积累起来非常可观。线程一旦建立默认会占据1MB左右的栈空间可以通过参数调整上千个线程同时存在内存压力直接拉满。手动管理线程的复用逻辑复杂。如果每个请求都创建一个线程→执行任务→销毁服务的吞吐量天花板很快就会触顶。这也是线程池ThreadPool存在的意义。线程池相当于一个员工复用中心有任务提交过来优先从池里挑空闲线程执行执行完毕线程不销毁而是回到池里等待下一个任务。这样一来建线程的开销只需要承担一次后续全是复用。2.3 Task是对任务的高层抽象线程池虽然解决了资源复用问题但直接用ThreadPool.QueueUserWorkItem写代码还是很别扭——你拿不到返回值没法方便地处理异常想要等某个任务完成再继续就得自己写回调写多了代码极其难看。Task的出现解决了这个问题。它把线程抽象成了任务。你关心的是我要做什么事情而不必关心哪个线程去做、这个线程什么时候创建或销毁。打个比方以前我要安排员工干活得自己去人才市场招人、管理考勤现在只需要把需求单Task提交给公司调度中心TaskScheduler调度中心负责安排合适的员工去执行你只管等结果。Taskint task Task.Run(() { // 模拟耗时计算 Thread.Sleep(500); return 42; }); int result await task; Console.WriteLine(result);这里看不到任何线程创建的痕迹但背后确实有一个线程池线程在执行这个任务。这就是现代C#并发编程的主旋律你操作的是任务而不是线程。手动操作Thread的场景越来越少了但它作为底层概念仍然需要理解后面讲死锁、线程安全时都绕不开。2.4 async/await把异步代码写成同步的样子async/await是C# 5.0引入的语法糖它彻底改变了异步编程的书写方式。在它之前写异步代码要用回调函数APM模式或者事件驱动EAP模式代码逻辑被打散成好几个片段可读性极差。async/await的工作方式有点像你点了杯奶茶后去逛超市。点单发起异步操作的时候并没有傻等而是拿到了一个小票Task然后你继续干自己的事继续执行调用方的代码。等奶茶做好了异步操作完成凭小票取货await返回结果。这段代码看起来像同步执行实际上不是async Taskstring GetUserInfoAsync() { var user await QueryUserAsync(userId); var orders await QueryOrdersAsync(userId); return ${user.Name}买了{orders.Count}件商品; }两个await并不是先把用户查出来再查订单——第一个await一碰到控制权就交还给了调用方线程去处理别的请求了。当QueryUserAsync完成时通过线程池线程继续往下执行到第二个await再挂起再去查订单。本质上就是多个异步操作在不同时间点穿插执行。好处显而易见一个线程可以同时服务多个逻辑上的工作单元吞吐量大幅提升。3. 线程生命周期与状态流转3.1 线程的各个状态线程不是一直在运行的它在生命周期中会在多个状态之间切换。C#中用ThreadState枚举表示但真正实际开发中更值得关注的是这几个状态未启动Unstarted创建了Thread对象但没调用Start()运行Running线程正在执行代码阻塞WaitSleepJoin线程在等待某个条件比如被Thread.Sleep、Monitor.Wait或Task.Wait挂起中止AbortRequested / Stopped请求终止或已终止这类状态现在基本已经不用了Thread.Abort在新版本中也不建议调用理解状态流转的核心意义在于状态切换不是免费的。线程从运行切换到阻塞再到重新被调度执行每一步都有开销这就是上下文切换Context Switch。频繁切换本质上是在浪费CPU时间因为你花时间在保存现场、恢复现场而不是在干正事。3.2 上下文切换到底有多贵每个进程或线程在CPU上跑的时候处理器内部的状态是一直在变的——寄存器里的值、程序计数器指向哪条指令、内存页表的缓存状态等等。切走一个任务再切回来需要保存当前的全部状态再载入下一个任务的状态这个过程就是上下文切换。直观感受一下开销一次上下文切换大约消耗几微秒的时间。几微秒听着很小但你要是每秒切换上万次浪费的CPU时间就相当可观了。更重要的是切换会使CPU缓存失效下一个任务进来的时候L1/L2缓存里存的是上一个任务的指令和数据需要重新加载这种隐性成本比切换本身还高。这说明一个道理不是线程开得越多越好。当线程数量超过CPU核心数太多时大量时间会耗在调度和切换上整体吞吐量反而下降。我们说合理并发度核心思路就是让每个CPU核保持忙碌但不过度争抢。3.3 前台线程和后台线程C#线程分成两类前台线程和后台线程。规则很简单进程退出条件是所有前台线程执行完毕后台线程不阻止进程退出。这带来一个常见的坑。如果你启动了一个后台线程做定时同步主线程干完活return了进程直接退出后台线程被强制终止数据没同步完就没下文了。反过来前台线程如果自己忘了退出比如写了个while(true)循环进程会一直挂着关都关不掉。默认情况下new Thread创建的是前台线程线程池线程都是后台线程。实际开发中我的建议是别太依赖这个特性来管理生命周期显式地使用CancellationToken协调线程退出比线程自杀式的强制终止要优雅得多。4. 同步与异步、并发与并行几组概念必须分清4.1 同步与异步是行为模式同步语义很直接我发起一个操作等待它完成然后继续往下走。异步则相反我发起一个操作不等它完成先干别的稍后再来取结果。它们关注的是单次操作的执行方式而不是多任务之间的关系。一个接口是同步还是异步取决于它对CPU和IO的利用方式。IO操作数据库查询、网络请求、文件读写的特点是一旦发出指令CPU就空闲了这时候非常适合异步——写代码让出CPU让线程去伺候别的请求。所以说async/await并不是为了加快单次请求的速度而是提高系统的整体吞吐量。这个认知特别重要。很多人写异步代码后发现单次执行时间并没有变快以为写错了实际上异步的价值在并发场景下才真正体现。4.2 并发与并行是资源利用方式并发指的是多个任务在时间线上交错执行。单核CPU也能做到并发因为操作系统用时间片轮转每个任务跑一小段时间再切走看起来像是同时跑。并行则要求硬件支持——多个CPU核心同一时刻不同核心真的在分别执行不同的任务。用一句话概括并发是结构并行是执行。你写并发代码但最终是否并行取决于系统的核心数和调度策略。在.NET里Task.Run代表逻辑上的并发让多个任务能够交错执行。如果你真的想让它们并行跑比如加速一个大批量计算核心数是4你把数据分成4块每块一个任务这样才可能真正利用多核。否则任务再多也只能排队执行。4.3 多线程、多进程与分布式这几层是递进的解决思路多线程同一进程内多个执行流共享内存开销小但需要处理同步问题多进程多个独立进程内存隔离稳定性更强但进程间通信成本高分布式多台机器协同工作解决了单机资源上限问题但引入网络延迟和一致性难题选择哪一层取决于瓶颈在哪里。数据处理CPU密集可以先尝试多线程并行第三方调用延迟高异步IO更合适怕某个模块崩溃拖垮整个服务可以考虑独立进程部署。跨机器水平扩展往往是最后的选择因为复杂度是最高的。5. 实操第一个多线程程序感受任务调度的不确定性5.1 最简单的多线程输出先来一个非常直观的实验for (int i 1; i 5; i) { Thread t new Thread(() Console.WriteLine($线程{i}执行)); t.Start(); } Console.WriteLine(主线程执行完毕);这段代码每次运行的结果都不一样甚至输出的语句顺序会错乱。这背后就是并发的事实线程调度的顺序不受代码书写顺序控制线程等待CPU分配时间片先分到的先执行。每条输出语句本身走了标准输出内部可能存在竞争所以能看到线程3执行和主线程执行完毕的交错关系。第一次接触多线程的人应该意识到你永远不要假设代码的执行顺序。多线程程序的执行结果应该以逻辑正确性为准而不是以输出顺序为准。5.2 三种写法的对比Thread版本最原始需要手动管理生命周期并且很难拿到返回值。Thread thread new Thread(() { Thread.Sleep(1000); Console.WriteLine(thread working); }); thread.Start(); thread.Join(); // 等待线程结束ThreadPool版本复用线程但API比较弱没有返回值、异常不好接。ThreadPool.QueueUserWorkItem(_ { Thread.Sleep(1000); Console.WriteLine(pool thread working); });Task版本现代推荐的写法返回值、异常、取消都支持。Task task Task.Run(() { Task.Delay(1000).Wait(); Console.WriteLine(task working); }); await task;对比很明显Task把细节隐藏在内部代码意图更清晰。而且Task支持组合——你可以Task.WhenAll等所有任务完成可以Task.WhenAny返回最先完成的任务这是原生Thread很难实现的。5.3 使用Task.WhenAll实现并行查询回到开头说的接口优化最核心的改动就是并行查询。假定三个数据源互不依赖完全可以一起查var userTask QueryUserAsync(userId); var inventoryTask QueryInventoryAsync(productIds); var logisticsTask QueryLogisticsAsync(trackingIds); await Task.WhenAll(userTask, inventoryTask, logisticsTask); var user await userTask; var inventory await inventoryTask; var logistics await logisticsTask;三个查询被同时发起总耗时约等于最慢的那个查询而不是三个查询之和。这就是多线程带来的最直接收益。当然如果三个查询共享同一个数据库而数据库连接是瓶颈这样改并不会提升多少甚至可能让数据库更忙——这就是为什么我们后面要聊并发级别的控制。6. 常见问题与避坑经验6.1 线程安全变量被多个线程同时改最经典的场景多个线程同时执行counter。int counter 0; for (int i 0; i 10000; i) { Task.Run(() counter); }最后counter的数值大概率不是10000因为counter底层是三条指令读取、加一、写回。两个线程同时读到同一个旧值都加一写回就把增量弄丢了。这属于线程安全问题是并发编程最普遍的坑。解决办法是用Interlocked.Increment或者加锁具体细节我会在后面专门写一篇。6.2 死锁两个线程相互等经典死锁场景线程A持有锁1等待锁2线程B持有锁2等待锁1。两个线程都等对方释放自己缺的资源导致谁也无法前进。写法上常见的是嵌套锁导致的。避免死锁的最简单策略是锁的顺序一致——所有线程都先锁1再锁2不要交叉。另一个策略是用超时Monitor.TryEnter等不到就放弃。再激进一点尽量避免同时持有多把锁。6.3 线程开太多反而变慢很多人一上来就Task.Run包裹所有逻辑以为并发了就等于快。结果线上CPU飙升接口反而更慢了。原因就是我前面提到的上下文切换开销以及CPU资源竞争。合理的方式是根据业务场景设定并发上限要么用SemaphoreSlim控制同时执行的数量要么用Parallel.ForEach并设置MaxDegreeOfParallelism。var options new ParallelOptions { MaxDegreeOfParallelism Environment.ProcessorCount * 2 }; Parallel.ForEach(items, options, item Process(item));这个配置表示最大并行数设为逻辑处理器数量的两倍对很多场景是一个比较保守的起点。6.4 调试技巧线程窗口和Parallel StacksVisual Studio里调试多线程程序时有两个窗口特别有用。线程窗口可以看到所有线程的状态、调用栈切换线程查看各自卡在哪里。Parallel Stacks窗口更适合看多个线程之间的相互关系死锁的时候可以通过它快速定位两个线程互相等待的路径。另一个实用调试方法是加超时。所有Task.Wait尽量给一个超时时间比如task.Wait(TimeSpan.FromSeconds(5))超时了返回false至少不会让程序永远挂在那里。排查死锁问题最痛苦的是不知道每个人堵在哪里超时机制相当于给现场拍照能帮你缩短很多排查时间。7. 写到最后分享几点体会先说明一个态度问题学多线程不是靠看书学会的一定要动手写。书上的例子都是精心设计好的时间、方式都是可控的而实际工程里的并发问题总是掺杂着各种环境因素。你一定得自己写几个多线程demo故意制造几个竞态跑坏了再修这个过程比看一百篇文章都管用。第二个体会是关于为什么先讲概念这个问题。很多初学者一上来就搜死锁怎么解决然后看了半天还是云里雾里根本原因在于连线程池、Task这些基本模型都没有建立起来。概念不清代码写得越多越容易产生玄学Bug。我见过好几个同事排查了一天最后发现是共享了一个不该共享的静态变量——这种问题如果对线程安全模型有清晰认知十分钟就能定位。我在实际开发中反复验证过一点现代C#项目里直接操作Thread的机会真的很少。绝大多数情况下Task.Run、async/await、Parallel这些高级抽象已经覆盖了98%的业务场景。但底层那些知识并没有过时反而越来越重要——因为只有你知道线程池的机理才明白为什么Task.Run不能想开多少开多少只有你知道线程状态切换的代价才理解为什么过度并行反而伤性能。这个系列的第一篇就到这里。下一篇我希望深入讲讲线程池的工作原理包括线程池的调优参数、线程饥饿的表现以及如何正确配置。纸上得来终觉浅建议你现在打开编辑器把上面那些示例代码跑一遍多观察几次输出结果的区别会有意想不到的收获。 1. 为什么需要多线程 —— 从一次线上事故说起大概两年前我在某公司做一次接口性能优化。那个接口本身功能不复杂就是从多个数据源拉取信息汇总后返回给前端。问题在于它是同步执行的——先查订单库再查库存库再查物流信息最后还要调一次第三方接口。单次请求耗时平均接近2秒。平时流量不大还扛得住一到大促流量上来线程池被占满后面所有请求排长队超时率肉眼可见地往上飙。这个场景在业务开发中太典型了。单线程最大的问题不是慢而是资源利用率低。等数据库返回的时候CPU实际上是空闲的等第三方接口响应的时候数据库连接也已经释放了。能不能做到等A的时候顺便把B做了这就是多线程要解决的核心问题。C#开发者走到一定阶段几乎都会遇到这几个坎界面卡死、接口超时、日志里出现诡异的并发异常。这些问题的解药或多或少的都指向多线程。但这恰恰是很多自学者的痛点——网上讲多线程的文章要么太浅只贴一堆代码没说为什么要么太深一上来就是锁、内存模型、指令重排直接把初学者劝退了。我计划用几篇文章把C#多线程这条路完整走一遍。第一篇专注基础概念把线程、线程池、任务、异步的区别讲清楚扫清术语上的障碍。后续会逐步深入到锁、并发集合、异步编程底层原理、常见的性能陷阱等等。这篇面向的是有C#语法基础但没系统学过并发的读者看完不会直接成为专家但至少能读懂大部分多线程代码并且敢在自己的项目里动手写了。2. 核心概念先理清楚线程、进程、线程池与任务2.1 进程和线程到底是什么关系很多初学者把进程和线程混为一谈。打个比方进程就像一家独立的公司有自己的办公场地独立的内存空间、自己的员工名册句柄表、自己的规章制度资源配额。而线程就是这家公司里的员工多个员工共享同一个办公场地一起读写同一块白板共享内存但各自的办公桌栈空间是独立的。在C#里启动一个.NET程序操作系统会给你创建一个进程。进程内部默认有一个主线程就是执行Main方法那个。创建额外的线程相当于在这个公司里多招了几个员工它们可以并行干活。关键点在于内存空间。进程之间内存是隔离的——进程A改了自己的变量进程B完全无感知但同一进程内的多个线程共享堆内存这意味着线程A创建的某个对象线程B可以直接访问。共享带来效率也带来麻烦——两个线程同时改同一个变量结果就可能错乱。这是后面所有并发问题的根源。2.2 线程是个昂贵资源别自己乱newC#里最基础的创建线程方式是new Thread(...)。很多教材会教你写出这样的代码Thread thread new Thread(() Console.WriteLine(我是子线程)); thread.Start();但实际生产中直接手动创建线程是非常不推荐的。原因很现实线程的创建和销毁是有成本的。每次创建线程操作系统要分配内核对象、初始化栈空间走一遍完整的初始化流程这些开销都实打实花在毫秒级别高频场景下积累起来非常可观。线程一旦建立默认会占据1MB左右的栈空间可以通过参数调整上千个线程同时存在内存压力直接拉满。手动管理线程的复用逻辑复杂。如果每个请求都创建一个线程→执行任务→销毁服务的吞吐量天花板很快就会触顶。这也是线程池ThreadPool存在的意义。线程池相当于一个员工复用中心有任务提交过来优先从池里挑空闲线程执行执行完毕线程不销毁而是回到池里等待下一个任务。这样一来建线程的开销只需要承担一次后续全是复用。2.3 Task是对任务的高层抽象线程池虽然解决了资源复用问题但直接用ThreadPool.QueueUserWorkItem写代码还是很别扭——你拿不到返回值没法方便地处理异常想要等某个任务完成再继续就得自己写回调写多了代码极其难看。Task的出现解决了这个问题。它把线程抽象成了任务。你关心的是我要做什么事情而不必关心哪个线程去做、这个线程什么时候创建或销毁。打个比方以前我要安排员工干活得自己去人才市场招人、管理考勤现在只需要把需求单Task提交给公司调度中心TaskScheduler调度中心负责安排合适的员工去执行你只管等结果。Taskint task Task.Run(() { // 模拟耗时计算 Thread.Sleep(500); return 42; }); int result await task; Console.WriteLine(result);这里看不到任何线程创建的痕迹但背后确实有一个线程池线程在执行这个任务。这就是现代C#并发编程的主旋律你操作的是任务而不是线程。手动操作Thread的场景越来越少了但它作为底层概念仍然需要理解后面讲死锁、线程安全时都绕不开。2.4 async/await把异步代码写成同步的样子async/await是C# 5.0引入的语法糖它彻底改变了异步编程的书写方式。在它之前写异步代码要用回调函数APM模式或者事件驱动EAP模式代码逻辑被打散成好几个片段可读性极差。async/await的工作方式有点像你点了杯奶茶后去逛超市。点单发起异步操作的时候并没有傻等而是拿到了一个小票Task然后你继续干自己的事继续执行调用方的代码。等奶茶做好了异步操作完成凭小票取货await返回结果。这段代码看起来像同步执行实际上不是async Taskstring GetUserInfoAsync() { var user await QueryUserAsync(userId); var orders await QueryOrdersAsync(userId); return ${user.Name}买了{orders.Count}件商品; }两个await并不是先把用户查出来再查订单——第一个await一碰到控制权就交还给了调用方线程去处理别的请求了。当QueryUserAsync完成时通过线程池线程继续往下执行到第二个await再挂起再去查订单。本质上就是多个异步操作在不同时间点穿插执行。好处显而易见一个线程可以同时服务多个逻辑上的工作单元吞吐量大幅提升。3. 线程生命周期与状态流转3.1 线程的各个状态线程不是一直在运行的它在生命周期中会在多个状态之间切换。C#中用ThreadState枚举表示但真正实际开发中更值得关注的是这几个状态未启动Unstarted创建了Thread对象但没调用Start()运行Running线程正在执行代码阻塞WaitSleepJoin线程在等待某个条件比如被Thread.Sleep、Monitor.Wait或Task.Wait挂起中止AbortRequested / Stopped请求终止或已终止这类状态现在基本已经不用了Thread.Abort在新版本中也不建议调用理解状态流转的核心意义在于状态切换不是免费的。线程从运行切换到阻塞再到重新被调度执行每一步都有开销这就是上下文切换Context Switch。频繁切换本质上是在浪费CPU时间因为你花时间在保存现场、恢复现场而不是在干正事。3.2 上下文切换到底有多贵每个进程或线程在CPU上跑的时候处理器内部的状态是一直在变的——寄存器里的值、程序计数器指向哪条指令、内存页表的缓存状态等等。切走一个任务再切回来需要保存当前的全部状态再载入下一个任务的状态这个过程就是上下文切换。直观感受一下开销一次上下文切换大约消耗几微秒的时间。几微秒听着很小但你要是每秒切换上万次浪费的CPU时间就相当可观了。更重要的是切换会使CPU缓存失效下一个任务进来的时候L1/L2缓存里存的是上一个任务的指令和数据需要重新加载这种隐性成本比切换本身还高。这说明一个道理不是线程开得越多越好。当线程数量超过CPU核心数太多时大量时间会耗在调度和切换上整体吞吐量反而下降。我们说合理并发度核心思路就是让每个CPU核保持忙碌但不过度争抢。3.3 前台线程和后台线程C#线程分成两类前台线程和后台线程。规则很简单进程退出条件是所有前台线程执行完毕后台线程不阻止进程退出。这带来一个常见的坑。如果你启动了一个后台线程做定时同步主线程干完活return了进程直接退出后台线程被强制终止数据没同步完就没下文了。反过来前台线程如果自己忘了退出比如写了个while(true)循环进程会一直挂着关都关不掉。默认情况下new Thread创建的是前台线程线程池线程都是后台线程。实际开发中我的建议是别太依赖这个特性来管理生命周期显式地使用CancellationToken协调线程退出比线程自杀式的强制终止要优雅得多。4. 同步与异步、并发与并行几组概念必须分清4.1 同步与异步是行为模式同步语义很直接我发起一个操作等待它完成然后继续往下走。异步则相反我发起一个操作不等它完成先干别的稍后再来取结果。它们关注的是单次操作的执行方式而不是多任务之间的关系。一个接口是同步还是异步取决于它对CPU和IO的利用方式。IO操作数据库查询、网络请求、文件读写的特点是一旦发出指令CPU就空闲了这时候非常适合异步——写代码让出CPU让线程去伺候别的请求。所以说async/await并不是为了加快单次请求的速度而是提高系统的整体吞吐量。这个认知特别重要。很多人写异步代码后发现单次执行时间并没有变快以为写错了实际上异步的价值在并发场景下才真正体现。4.2 并发与并行是资源利用方式并发指的是多个任务在时间线上交错执行。单核CPU也能做到并发因为操作系统用时间片轮转每个任务跑一小段时间再切走看起来像是同时跑。并行则要求硬件支持——多个CPU核心同一时刻不同核心真的在分别执行不同的任务。用一句话概括并发是结构并行是执行。你写并发代码但最终是否并行取决于系统的核心数和调度策略。在.NET里Task.Run代表逻辑上的并发让多个任务能够交错执行。如果你真的想让它们并行跑比如加速一个大批量计算核心数是4你把数据分成4块每块一个任务这样才可能真正利用多核。否则任务再多也只能排队执行。4.3 多线程、多进程与分布式这几层是递进的解决思路多线程同一进程内多个执行流共享内存开销小但需要处理同步问题多进程多个独立进程内存隔离稳定性更强但进程间通信成本高分布式多台机器协同工作解决了单机资源上限问题但引入网络延迟和一致性难题选择哪一层取决于瓶颈在哪里。数据处理CPU密集可以先尝试多线程并行第三方调用延迟高异步IO更合适怕某个模块崩溃拖垮整个服务可以考虑独立进程部署。跨机器水平扩展往往是最后的选择因为复杂度是最高的。5. 实操第一个多线程程序感受任务调度的不确定性5.1 最简单的多线程输出先来一个非常直观的实验for (int i 1; i 5; i) { Thread t new Thread(() Console.WriteLine($线程{i}执行)); t.Start(); } Console.WriteLine(主线程执行完毕);这段代码每次运行的结果都不一样甚至输出的语句顺序会错乱。这背后就是并发的事实线程调度的顺序不受代码书写顺序控制线程等待CPU分配时间片先分到的先执行。每条输出语句本身走了标准输出内部可能存在竞争所以能看到线程3执行和主线程执行完毕的交错关系。第一次接触多线程的人应该意识到你永远不要假设代码的执行顺序。多线程程序的执行结果应该以逻辑正确性为准而不是以输出顺序为准。5.2 三种写法的对比Thread版本最原始需要手动管理生命周期并且很难拿到返回值。Thread thread new Thread(() { Thread.Sleep(1000); Console.WriteLine(thread working); }); thread.Start(); thread.Join(); // 等待线程结束ThreadPool版本复用线程但API比较弱没有返回值、异常不好接。ThreadPool.QueueUserWorkItem(_ { Thread.Sleep(1000); Console.WriteLine(pool thread working); });Task版本现代推荐的写法返回值、异常、取消都支持。Task task Task.Run(() { Task.Delay(1000).Wait(); Console.WriteLine(task working); }); await task;对比很明显Task把细节隐藏在内部代码意图更清晰。而且Task支持组合——你可以Task.WhenAll等所有任务完成可以Task.WhenAny返回最先完成的任务这是原生Thread很难实现的。5.3 使用Task.WhenAll实现并行查询回到开头说的接口优化最核心的改动就是并行查询。假定三个数据源互不依赖完全可以一起查var userTask QueryUserAsync(userId); var inventoryTask QueryInventoryAsync(productIds); var logisticsTask QueryLogisticsAsync(trackingIds); await Task.WhenAll(userTask, inventoryTask, logisticsTask); var user await userTask; var inventory await inventoryTask; var logistics await logisticsTask;三个查询被同时发起总耗时约等于最慢的那个查询而不是三个查询之和。这就是多线程带来的最直接收益。当然如果三个查询共享同一个数据库而数据库连接是瓶颈这样改并不会提升多少甚至可能让数据库更忙——这就是为什么我们后面要聊并发级别的控制。6. 常见问题与避坑经验6.1 线程安全变量被多个线程同时改最经典的场景多个线程同时执行counter。int counter 0; for (int i 0; i 10000; i) { Task.Run(() counter); }最后counter的数值大概率不是10000因为counter底层是三条指令读取、加一、写回。两个线程同时读到同一个旧值都加一写回就把增量弄丢了。这属于线程安全问题是并发编程最普遍的坑。解决办法是用Interlocked.Increment或者加锁具体细节我会在后面专门写一篇。6.2 死锁两个线程相互等经典死锁场景线程A持有锁1等待锁2线程B持有锁2等待锁1。两个线程都等对方释放自己缺的资源导致谁也无法前进。写法上常见的是嵌套锁导致的。避免死锁的最简单策略是锁的顺序一致——所有线程都先锁1再锁2不要交叉。另一个策略是用超时Monitor.TryEnter等不到就放弃。再激进一点尽量避免同时持有多把锁。6.3 线程开太多反而变慢很多人一上来就Task.Run包裹所有逻辑以为并发了就等于快。结果线上CPU飙升接口反而更慢了。原因就是我前面提到的上下文切换开销以及CPU资源竞争。合理的方式是根据业务场景设定并发上限要么用SemaphoreSlim控制同时执行的数量要么用Parallel.ForEach并设置MaxDegreeOfParallelism。var options new ParallelOptions { MaxDegreeOfParallelism Environment.ProcessorCount * 2 }; Parallel.ForEach(items, options, item Process(item));这个配置表示最大并行数设为逻辑处理器数量的两倍对很多场景是一个比较保守的起点。6.4 调试技巧线程窗口和Parallel StacksVisual Studio里调试多线程程序时有两个窗口特别有用。线程窗口可以看到所有线程的状态、调用栈切换线程查看各自卡在哪里。Parallel Stacks窗口更适合看多个线程之间的相互关系死锁的时候可以通过它快速定位两个线程互相等待的路径。另一个实用调试方法是加超时。所有Task.Wait尽量给一个超时时间比如task.Wait(TimeSpan.FromSeconds(5))超时了返回false至少不会让程序永远挂在那里。排查死锁问题最痛苦的是不知道每个人堵在哪里超时机制相当于给现场拍照能帮你缩短很多排查时间。7. 写到最后分享几点体会先说明一个态度问题学多线程不是靠看书学会的一定要动手写。书上的例子都是精心设计好的时间、方式都是可控的而实际工程里的并发问题总是掺杂着各种环境因素。你一定得自己写几个多线程demo故意制造几个竞态跑坏了再修这个过程比看一百篇文章都管用。第二个体会是关于为什么先讲概念这个问题。很多初学者一上来就搜死锁怎么解决然后看了半天还是云里雾里根本原因在于连线程池、Task这些基本模型都没有建立起来。概念不清代码写得越多越容易产生玄学Bug。我见过好几个同事排查了一天最后发现是共享了一个不该共享的静态变量——这种问题如果对线程安全模型有清晰认知十分钟就能定位。我在实际开发中反复验证过一点现代C#项目里直接操作Thread的机会真的很少。绝大多数情况下Task.Run、async/await、Parallel这些高级抽象已经覆盖了98%的业务场景。但底层那些知识并没有过时反而越来越重要——因为只有你知道线程池的机理才明白为什么Task.Run不能想开多少开多少只有你知道线程状态切换的代价才理解为什么过度并行反而伤性能。这个系列的第一篇就到这里。下一篇我希望深入讲讲线程池的工作原理包括线程池的调优参数、线程饥饿的表现以及如何正确配置。纸上得来终觉浅建议你现在打开编辑器把上面那些示例代码跑一遍多观察几次输出结果的区别会有意想不到的收获。