接手过某数据导入服务的改造后我对“多线程”三个字彻底改观。网上讲 C# 多线程的教程十个里有九个在教你“怎么创建几百个线程然后跑一个计数器累加”。看完觉得自己懂了一放进真实项目才发现麻烦全在别的地方线程池饥饿、锁粒度、异步上下文死锁、上下文切换开销任何一个都能让你通宵排查。这篇文章我想带你从“会写并发代码”跳到“能设计并发方案”把背后的原理、选型逻辑、实操步骤和踩坑过程一次讲透。一句话先记住多线程最值钱的不是把线程开出来而是让一堆并发工作有序协作、不互相踩踏。1. 先把线程的“成本账”算清楚1.1 线程不是免费的午餐很多人以为多开线程就是“多用几个工人”问题在于线程这个“工人”本身是要发工资的。默认情况下每个线程要分配约 1 MB 的栈空间线程调度要切入内核态系统需要保存和恢复寄存器、更新内核调度队列这个过程叫上下文切换。一次上下文切换在纳秒到微秒级听起来不多但如果几百上千个线程频繁切换CPU 的时间片大量耗在“换人”而不是“干活”上性能反而断崖下跌。我记得某项目做大量文件解析时最初方案是每个文件开一个线程文件一多CPU 直接 100%磁盘 IO 还在等但任务完成时间比串行还慢。原因就是线程数远超 CPU 核心数系统大部分时间在处理“谁先跑”的问题而不是真正解析文件。这里有个简单换算思路一个 8 核 16 线程的机器理论上能做到“同时执行”的任务数也就 16 个左右。超过这个数量后新增线程几乎不会带来并行度提升反而引入调度开销。你在设计并发模型时最好先问一句我开的每个线程是在“并行处理”还是在“排队等调度”1.2 什么情况下才值得“亲手开线程”既然线程这么贵是不是就应该完全避开 Thread也不是。有些场景确实需要独立生命周期且长期存在的线程比如 Windows 服务后台轮询、专用通信端口监听、需要脱离线程池管理的长驻任务。我一般只用 Thread 处理两种情况一种是你需要一个带有独立运行状态、在进程生命周期内常驻的 worker另一种是你明确要对线程设置 Priority、修改 ThreadState或者需要更底层的控制能力。其余临时性的并发工作优先考虑线程池和 Task。为什么因为线程池在线程使用上做了复用和延迟创建任务多时也能平滑排队避免“批量为每个短任务造一个线程”的灾难性开销。判断标准也不复杂任务平均执行时间远大于线程创建开销且任务数量相对固定可以考虑独立线程任务数量大、单次执行短就交给线程池。我用这句话做了不少架构上的取舍还没有失手过。2. Task 和线程池你的主力军到底怎么用2.1 Task 不是“更快的线程”Task 和 Thread 最大的区别不是性能而是抽象层级。Task 表示一项“可调度的作业”本身不一定是线程它默认在线程池上排队执行调度器决定什么时候、用哪个线程去跑它。而 Thread 是操作系统层面的执行体。随手写Task.Run时你其实是在说“把这份工作投到一个有调度策略的队列里”。线程池会根据当前负载、核心数、任务排队情况动态决定要不要新增线程。这个设计带来的好处是你不太会在任务量小的时候白白养着一堆线程也不会在任务量突然变大时瞬间崩塌代价是少了“指哪打哪”的即时性。我在某文件导出项目里用Task.WhenAll同时发起若干导出任务每个任务内部还会再拆子任务。如果换用 Thread光是创建和销毁的管理代码就够写一天了更别提异常处理和数据聚合。所以现代 C# 推荐的做法是能描述作业就不要操作线程。2.2 线程池参数到底该不该调一个高频问题生产上要不要调ThreadPool.SetMinThreads我的答案是“大多数情况下要谨慎但有些场景必须调”。先看默认行为。线程池有个“注入速率”机制初始线程数有限任务排队后不会马上疯狂建线程而是每隔一段时间尝试新增。高并发突发场景下可能出现任务已在排队、线程却还没来得及建立的情况表现就是“响应卡顿几秒后突然恢复”。如果你做的是网关转发、实时消息处理这类对延迟敏感的服务这种“爬坡”过程不可接受。我实际处理过的一个下单推送服务高峰期任务排队客户端不断重试加重了堆积。排查后确认是线程池爬坡导致的吞吐尖刺于是在服务启动时显式预热ThreadPool.SetMinThreads(64, 64);这里 64 并不是拍脑袋是根据高峰期并发任务数、平均单任务耗时以及机器核心数反推出来的一个经验值。设置后线程池在最开始时就能维持足够处理能力避免突刺。但要提醒你不要把SetMinThreads调成一个巨大数字去“硬扛”糟糕的业务设计。线程池最小值调大意味着即使空闲也可能占用较多内存和上下文槽位。正确姿势是先优化任务本身的耗时和阻塞问题再调节线程池参数。调参只是消除调度初期抖动的手段不是性能瓶颈的解药。2.3 用 Task 时没留意的坑Task.Run里跑的是同步代码它适合 CPU 密集型工作。但如果任务内部调用了一个异步接口直接在Task.Run外面再包一层就没有意义了。Task.Run把一个同步委托变成在线程池上执行的作业而async方法本身在遇到真正等待时会释放线程。不要把二者叠加出“多线程焦虑”来。还有一个容易被忽略的不是所有 Task 都值得放进线程池。比如你只是需要延迟一下再继续用Task.Delay(TimeSpan.FromSeconds(5))是完全没问题的它会挂起而非占用线程。如果你在异步方法里写Thread.Sleep就白白占着一个线程池线程在那睡觉这就是线程饥饿的常见来源之一。很多新人在写异步接口时习惯给每个await后面再卑微地加一个Task.Run试图“更异步”。这其实是反向操作异步的价值是释放线程等待 IO而不是额外制造线程来排队。这一点想通之后并发问题少了一半。3. 线程安全锁只是手段不是目的3.1 lock 到底锁住了什么lock关键字用起来很简单但理解它的本质很重要。lock(obj)编译后的等价逻辑是Monitor.Enter(obj)try/finallyMonitor.Exit(obj)它锁的是对象头里的一个标志位代表“当前这个临界区被某个线程拥有”。重要的话多说一遍锁的是那段代码块的访问权不是“锁住变量”本身。正因如此锁对象的选择非常关键。很多新手喜欢lock(new object())在方法内每次 new 一个对象这等于没有锁因为每个线程进去锁的是不同对象。也有老代码喜欢lock(this)或lock(typeof(Foo))这类写法对外部可见一旦有其他代码用同一个对象锁就可能产生毫无必要的互斥甚至死锁风险。我常用的约束有三条第一锁对象声明为私有只读字段第二锁对象不被任何外部代码引用第三临界区内不写耗时操作和 IO。private readonly object _syncRoot new(); public void AddOrUpdate(string key, string value) { lock (_syncRoot) { // 只做内存字段操作不在这里写文件、访问网络 } }别在锁里面做长时间等待尤其是等另一个锁。锁住的时间越长别的线程阻塞越久系统整体吞吐越低。高性能并发系统里锁的“粒度”比锁本身重要得多。3.2 多种锁方案怎么选.NET 里锁方案很多选型的核心维度是允许多少读者、多少个写者、能不能异步等待。方案适用场景使用注意lock / Monitor临界区短小、竞争不激烈不能 async 等待ReaderWriterLockSlim多读少写写锁会让读者等待SemaphoreSlim限流、信号量控制支持 WaitAsyncInterlocked计数、交换、自增仅限简单原子操作spinlock / 自旋临界区极短不适用于长时间等待简单说能用Interlocked解决的不要上lock能用读写锁解决的不要用独占锁。比如要统计一个计数直接用Interlocked.Increment(ref _count);不需要锁整个if判断。Interlocked对应 CPU 层级的原子指令不涉及内核态锁等待在超高并发下差异非常明显。SemaphoreSlim则常用于“限制并发数量”的场景。比如某数据库连接池只允许同时 5 个写入连接可以把它当作一个计数器信号量。它在异步场景下配合WaitAsync(CancellationToken)非常好用这和lock那种“抢到就锁死抢不到就阻塞线程”完全不同。3.3 上锁之前先想想能不能不上锁这句话听起来像废话但很多并发 bug 其实是“用锁硬撑出来的”。如果共享数据可以被设计成不可变对象或者不同线程操作的数据天然不重叠就根本不需要锁。举个例子你有多个订单要处理每个订单被独立计算后再汇总。这时与其维护一个共享集合然后用锁保护不如让每个任务返回自己的结果最后用Task.WhenAll统一聚合。只要没有写入同一个内存位置就没有竞争条件自然不需要锁。再比如ConcurrentDictionary、ConcurrentQueue这些并发集合内部已经封装了细粒度的同步机制。不要把它们放在大锁里使用否则并发集合的优势全被锁头抵消了。我之前见过一段代码为了修改 ConcurrentDictionary 里的某个 value给整个遍历加了个大锁结果并发请求全堵在锁上改造后直接换TryUpdate吞吐量翻了几倍。4. async/await异步和多线程是两个维度4.1 异步不“开线程”但能“省线程”新手最容易混淆的概念async方法不等于多线程。它跟线程最直接的关系是遇到真正的异步等待时当前线程会被释放回线程池等 IO 完成后再回来继续执行。举个例子从接口读数据用同步的方式写线程会一直阻塞等待响应用await HttpClient.GetStringAsync(...)这个线程就可以先去处理其他请求数据回来后再接着执行。异步的价值在于“等待时不占用人手”而不是把更多人拉进来干活。所以我一直建议写 IO 密集的业务代码用异步方式推进写计算密集的核心算法才考虑并行和线程。前者是“减少线程浪费”后者才是“增加线程并行”。这两类问题的解法完全不同混在一起才是噩梦的开始。4.2 状态机不深挖但这些坑必须知道async/await背后是编译器生成的状态机每次await都会把“接下来要做的事情”注册为一个 continuation。看起来像写同步代码实际执行顺序被拆成了多段。比较需要留意的是同步上下文问题。在 UI 程序或某些自带上下文的环境里await后默认要“回到原来的上下文”。如果在 UI 线程上阻塞等待一个异步任务比如.Result、.GetAwaiter().GetResult()就可能出现“UI 线程在等任务任务又在等回到 UI 线程”的死锁。应对方案有两个一是从最外层就开始异步不把异步方法包在同步等待里二是在库代码里使用ConfigureAwait(false)告诉状态机不要尝试回原来上下文。string content await httpClient.GetStringAsync(url).ConfigureAwait(false);这句话的含义是代码恢复执行时不需要回到调用者的上下文直接在线程池线程上继续即可。这能有效避免 UI / ASP.NET 环境下的隐式死锁但也意味着后续代码不能轻易访问 UI 控件或请求上下文。另外async void要尽量避免。它只在事件处理器里是合理写法其余场景一旦异常抛出来直接变成一个难以捕获的未处理异常。普通方法应该一律返回Task或TaskT。4.3 同步与异步的边界怎么控制在实际项目中我见过很糟糕的“全链路异步”风潮明明是一个快速内存计算偏要await Task.Run再转一圈。这没有好处反而增加了状态机开销和调度延迟。我的经验是方法里如果没有真正的 IO 等待或不可控耗时步骤直接写成同步方法然后在边界处异步化即可。例如 Controller 层调一个同步服务如果服务本身是纯计算就直接返回结果不要刻意await Task.FromResult。只有涉及网络、磁盘、外部接口时异步才值得。说到同步调异步还有个老掉牙但一直在踩的坑不要用Task.Wait()和Task.Result硬等。我接手某 API 时发现大量异步接口都是.Result阻塞的一遇到高并发就线程池饥饿请求超时率飙升。后来统一改成async一路到底问题缓解了 70% 以上。5. 三种常见并发模式与实操记录5.1 生产者 / 消费者模式和 Channel有一类并发问题特别典型一个线程不停产生数据另一个线程负责消费。最自然的方案是队列。.NET 里有ConcurrentQueue和现代异步环境下的Channel。Channel是个好东西它把生产者和消费者的关系描述得很清晰。生产者只管往队列里写消费者只管读两者互不知道对方存在。它是一种“解耦 背压”的设计可以实现限流、削峰。某数据采集服务里我用了有界 Channel 来限制积压量var options new BoundedChannelOptions(1000) { FullMode BoundedChannelFullMode.Wait }; var channel Channel.CreateBoundedOrder(options);生产者使用WriteAsync消费方使用ReadAllAsync循环处理。当队列满时生产方会等待相当于一种“背压机制”防止无界积压拖垮内存。这个设计让生产线上的任务“不慌不忙”比单纯用while (true) { queue.TryDequeue(...) }干净得多。在 .NET Framework 老项目或者不想引入新依赖的情况下BlockingCollection是另一个熟悉的选择它支持有界容量和阻塞操作更偏传统多线程风格。两套工具的选型要点是如果你在写新代码并且能使用较新运行时直接选 Channel如果是在维护老系统BlockingCollection 更顺滑。5.2 CPU 密集计算Parallel 的正确用法如果你有一批计算任务要同时跑完用Parallel.For比手动Task.Run循环更安全。它会自动做分区根据核心数和工作量动态调整并行度并把结果聚合逻辑简化。我写过一段图像批处理逻辑对几千张图片做滤镜计算。直接写循环太慢手动开线程又怕把 CPU 占满于是用Parallel.ForEach加ParallelOptions限制并发度var options new ParallelOptions { MaxDegreeOfParallelism Environment.ProcessorCount / 2 }; Parallel.ForEach(imageList, options, image { ProcessOneImage(image); });这里的限制不是拍脑袋生产环境同一台服务器还会跑其他服务把逻辑核数全占满会影响他人。保留一半核心给 IO 和系统调度整体体验反而更稳。但要注意Parallel适合计算型任务不适合任务里还包了异步 IO 的情况。一旦你在并行循环里Task.Delay或者调用外部 API这个线程在等待时依然被占住线程池的效率就崩了。混合场景应该用Task.WhenAllSemaphoreSlim做一个异步并发池。5.3 分批处理的节奏控制高并发导入这类场景“一次派发所有任务”并不是好主意。一来系统瞬时压力太大二来一旦中途出问题回滚和重试的粒度都很难控制。我在某次的库存同步项目里把任务按批次拆分每批 200 个每批之间留出短暂间隔既保证吞吐又避免连续大量 IO 请求打爆目标系统。简单说就是for (int offset 0; offset total; offset batchSize) { var batch data.Skip(offset).Take(batchSize).ToArray(); var tasks batch.Select(i ProcessItemAsync(i)); await Task.WhenAll(tasks); await Task.Delay(50); // 控制节奏 }这里的 50 毫秒不是省 CPU是给外部系统一个缓冲时间防止限流返回错误后还要重试反而更慢。很多时候“快”不是靠一次全切开出来的而是靠让系统处于不崩溃的稳定状态。6. 排查和避坑实录那些让人想摔键盘的问题6.1 线程开了几百个程序却越来越卡某次我接手一个 Windows 服务内存占用不高但 CPU 持续飙升任务处理速度越来越慢。抓完 dump 一看线程池里几百个线程绝大多数状态是“阻塞等待”。再往里追发现核心逻辑里有大量SemaphoreSlim.Wait()嵌套而信号量初始值太小导致线程互相等待线程池判断“线程不够”继续增加线程结果越加越卡。排查过程可以简单总结为先看是 CPU 高还是线程数高再去 dump 里看线程栈再确认是否有同步等待链。用录dump的方式非常直观几个线程卡在哪一行、等哪个锁对象一目了然。这类问题很少是“线程数不够”而是“不应该阻塞的地方阻塞了”。想办法把阻塞等待换成异步等待或者对关键资源做更合理的并发控制线程数会自然下降性能反而提升。6.2 高并发下偶发数据错乱另一种让人头疼的问题是“运行十次有两次数据不对”。这类 bug 有明显的随机性通常和竞态条件有关。你以为是终于“多线程跑起来了”结果是共享状态被多个线程交替改写最终结果取决于调度顺序。我之前遇到一个订单号生成逻辑在并发下出现重复订单号。最初排查时大家怀疑是数据库唯一索引的问题后来定位到是内存里一个全局计数器被并发自增而读取和1不是原子的。改成Interlocked.Increment后重复问题直接消失。排查竞态条件的实用技巧是给日志加线程 ID 和上下文信息复现时开启详细日志再配合 Visual Studio 的“并行任务”窗口观察各线程的执行位置。如果你能看到两个线程同时进入了同一段代码大概率就是临界区没保护或者锁对象用错了。6.3 性能没升反降的隐形杀手有时候并发改造后性能不仅没提升反而下降。最常见的原因是“任务切得太碎”或“锁的竞争太严重”。一个任务本身只需要 1 毫秒你把它拆成 10 个并行子任务每个子任务还要加锁访问共享集合。结果是并行带来的收益远远小于加锁和上下文切换的代价性能自然不升反降。在评估并发方案时可以先计算理论收益设有 N 个核心任务并行部分占比为 P根据 Amdahl 定律加速比上限是 1 / ((1-P) P/N)。换句话说如果 90% 的时间都在串行更新共享数据结构那么无论如何加线程性能天花板都很低。这也是为什么“锁越少越好”不是口号是架构设计里的硬道理。6.4 几句话版本的排查速查表症状排查方向常见解法线程数疯狂上涨看线程栈是否有阻塞等待把阻塞改为异步 / 调整信号量偶发数据错乱找共享变量读写点加锁、用并发集合或 Interlocked吞吐量上不去看抢锁等待和上下文切换减小锁粒度、分片处理请求偶发超时看线程池爬坡和同步等待预热线程池、异步化链路async 方法卡死看同步上下文依赖去掉 .Result 硬等配置 ConfigureAwait(false)这个表是我每次重构并发代码前都要过一遍的清单能省下很多无效排查时间。写在最后的个人心得我带过几个新手做并发项目发现最容易出问题的不是 API 用错了而是“根本不知道自己写的东西会同时跑多少个实例”。所以我在代码评审里养成了一个习惯每个涉及共享状态的地方都会先问三个问题这里的数据真的需要被多个线程同时改吗等待资源时线程是被阻塞了还是可以去做别的事锁的范围能再缩小一点吗或者干脆消除锁多线程这门功夫单靠“会调 API”走不远真正拉开差距的是对线程成本、锁取舍、任务拆分的理解。你在工程里踩过的每一个死锁、每一次线程池饥饿最后都会变成对并发系统的直觉。这种直觉不是看文档看出来的是真把代码在高负载环境下跑一遍、再把失败现场分析一遍以后攒出来的经验。 
长河君 · 2026/10/14 22:37:24 · 阅读 1.2k C#多线程核心指南：线程池、async/await与并发设计实战
接手过某数据导入服务的改造后我对“多线程”三个字彻底改观。网上讲 C# 多线程的教程十个里有九个在教你“怎么创建几百个线程然后跑一个计数器累加”。看完觉得自己懂了一放进真实项目才发现麻烦全在别的地方线程池饥饿、锁粒度、异步上下文死锁、上下文切换开销任何一个都能让你通宵排查。这篇文章我想带你从“会写并发代码”跳到“能设计并发方案”把背后的原理、选型逻辑、实操步骤和踩坑过程一次讲透。一句话先记住多线程最值钱的不是把线程开出来而是让一堆并发工作有序协作、不互相踩踏。1. 先把线程的“成本账”算清楚1.1 线程不是免费的午餐很多人以为多开线程就是“多用几个工人”问题在于线程这个“工人”本身是要发工资的。默认情况下每个线程要分配约 1 MB 的栈空间线程调度要切入内核态系统需要保存和恢复寄存器、更新内核调度队列这个过程叫上下文切换。一次上下文切换在纳秒到微秒级听起来不多但如果几百上千个线程频繁切换CPU 的时间片大量耗在“换人”而不是“干活”上性能反而断崖下跌。我记得某项目做大量文件解析时最初方案是每个文件开一个线程文件一多CPU 直接 100%磁盘 IO 还在等但任务完成时间比串行还慢。原因就是线程数远超 CPU 核心数系统大部分时间在处理“谁先跑”的问题而不是真正解析文件。这里有个简单换算思路一个 8 核 16 线程的机器理论上能做到“同时执行”的任务数也就 16 个左右。超过这个数量后新增线程几乎不会带来并行度提升反而引入调度开销。你在设计并发模型时最好先问一句我开的每个线程是在“并行处理”还是在“排队等调度”1.2 什么情况下才值得“亲手开线程”既然线程这么贵是不是就应该完全避开 Thread也不是。有些场景确实需要独立生命周期且长期存在的线程比如 Windows 服务后台轮询、专用通信端口监听、需要脱离线程池管理的长驻任务。我一般只用 Thread 处理两种情况一种是你需要一个带有独立运行状态、在进程生命周期内常驻的 worker另一种是你明确要对线程设置 Priority、修改 ThreadState或者需要更底层的控制能力。其余临时性的并发工作优先考虑线程池和 Task。为什么因为线程池在线程使用上做了复用和延迟创建任务多时也能平滑排队避免“批量为每个短任务造一个线程”的灾难性开销。判断标准也不复杂任务平均执行时间远大于线程创建开销且任务数量相对固定可以考虑独立线程任务数量大、单次执行短就交给线程池。我用这句话做了不少架构上的取舍还没有失手过。2. Task 和线程池你的主力军到底怎么用2.1 Task 不是“更快的线程”Task 和 Thread 最大的区别不是性能而是抽象层级。Task 表示一项“可调度的作业”本身不一定是线程它默认在线程池上排队执行调度器决定什么时候、用哪个线程去跑它。而 Thread 是操作系统层面的执行体。随手写Task.Run时你其实是在说“把这份工作投到一个有调度策略的队列里”。线程池会根据当前负载、核心数、任务排队情况动态决定要不要新增线程。这个设计带来的好处是你不太会在任务量小的时候白白养着一堆线程也不会在任务量突然变大时瞬间崩塌代价是少了“指哪打哪”的即时性。我在某文件导出项目里用Task.WhenAll同时发起若干导出任务每个任务内部还会再拆子任务。如果换用 Thread光是创建和销毁的管理代码就够写一天了更别提异常处理和数据聚合。所以现代 C# 推荐的做法是能描述作业就不要操作线程。2.2 线程池参数到底该不该调一个高频问题生产上要不要调ThreadPool.SetMinThreads我的答案是“大多数情况下要谨慎但有些场景必须调”。先看默认行为。线程池有个“注入速率”机制初始线程数有限任务排队后不会马上疯狂建线程而是每隔一段时间尝试新增。高并发突发场景下可能出现任务已在排队、线程却还没来得及建立的情况表现就是“响应卡顿几秒后突然恢复”。如果你做的是网关转发、实时消息处理这类对延迟敏感的服务这种“爬坡”过程不可接受。我实际处理过的一个下单推送服务高峰期任务排队客户端不断重试加重了堆积。排查后确认是线程池爬坡导致的吞吐尖刺于是在服务启动时显式预热ThreadPool.SetMinThreads(64, 64);这里 64 并不是拍脑袋是根据高峰期并发任务数、平均单任务耗时以及机器核心数反推出来的一个经验值。设置后线程池在最开始时就能维持足够处理能力避免突刺。但要提醒你不要把SetMinThreads调成一个巨大数字去“硬扛”糟糕的业务设计。线程池最小值调大意味着即使空闲也可能占用较多内存和上下文槽位。正确姿势是先优化任务本身的耗时和阻塞问题再调节线程池参数。调参只是消除调度初期抖动的手段不是性能瓶颈的解药。2.3 用 Task 时没留意的坑Task.Run里跑的是同步代码它适合 CPU 密集型工作。但如果任务内部调用了一个异步接口直接在Task.Run外面再包一层就没有意义了。Task.Run把一个同步委托变成在线程池上执行的作业而async方法本身在遇到真正等待时会释放线程。不要把二者叠加出“多线程焦虑”来。还有一个容易被忽略的不是所有 Task 都值得放进线程池。比如你只是需要延迟一下再继续用Task.Delay(TimeSpan.FromSeconds(5))是完全没问题的它会挂起而非占用线程。如果你在异步方法里写Thread.Sleep就白白占着一个线程池线程在那睡觉这就是线程饥饿的常见来源之一。很多新人在写异步接口时习惯给每个await后面再卑微地加一个Task.Run试图“更异步”。这其实是反向操作异步的价值是释放线程等待 IO而不是额外制造线程来排队。这一点想通之后并发问题少了一半。3. 线程安全锁只是手段不是目的3.1 lock 到底锁住了什么lock关键字用起来很简单但理解它的本质很重要。lock(obj)编译后的等价逻辑是Monitor.Enter(obj)try/finallyMonitor.Exit(obj)它锁的是对象头里的一个标志位代表“当前这个临界区被某个线程拥有”。重要的话多说一遍锁的是那段代码块的访问权不是“锁住变量”本身。正因如此锁对象的选择非常关键。很多新手喜欢lock(new object())在方法内每次 new 一个对象这等于没有锁因为每个线程进去锁的是不同对象。也有老代码喜欢lock(this)或lock(typeof(Foo))这类写法对外部可见一旦有其他代码用同一个对象锁就可能产生毫无必要的互斥甚至死锁风险。我常用的约束有三条第一锁对象声明为私有只读字段第二锁对象不被任何外部代码引用第三临界区内不写耗时操作和 IO。private readonly object _syncRoot new(); public void AddOrUpdate(string key, string value) { lock (_syncRoot) { // 只做内存字段操作不在这里写文件、访问网络 } }别在锁里面做长时间等待尤其是等另一个锁。锁住的时间越长别的线程阻塞越久系统整体吞吐越低。高性能并发系统里锁的“粒度”比锁本身重要得多。3.2 多种锁方案怎么选.NET 里锁方案很多选型的核心维度是允许多少读者、多少个写者、能不能异步等待。方案适用场景使用注意lock / Monitor临界区短小、竞争不激烈不能 async 等待ReaderWriterLockSlim多读少写写锁会让读者等待SemaphoreSlim限流、信号量控制支持 WaitAsyncInterlocked计数、交换、自增仅限简单原子操作spinlock / 自旋临界区极短不适用于长时间等待简单说能用Interlocked解决的不要上lock能用读写锁解决的不要用独占锁。比如要统计一个计数直接用Interlocked.Increment(ref _count);不需要锁整个if判断。Interlocked对应 CPU 层级的原子指令不涉及内核态锁等待在超高并发下差异非常明显。SemaphoreSlim则常用于“限制并发数量”的场景。比如某数据库连接池只允许同时 5 个写入连接可以把它当作一个计数器信号量。它在异步场景下配合WaitAsync(CancellationToken)非常好用这和lock那种“抢到就锁死抢不到就阻塞线程”完全不同。3.3 上锁之前先想想能不能不上锁这句话听起来像废话但很多并发 bug 其实是“用锁硬撑出来的”。如果共享数据可以被设计成不可变对象或者不同线程操作的数据天然不重叠就根本不需要锁。举个例子你有多个订单要处理每个订单被独立计算后再汇总。这时与其维护一个共享集合然后用锁保护不如让每个任务返回自己的结果最后用Task.WhenAll统一聚合。只要没有写入同一个内存位置就没有竞争条件自然不需要锁。再比如ConcurrentDictionary、ConcurrentQueue这些并发集合内部已经封装了细粒度的同步机制。不要把它们放在大锁里使用否则并发集合的优势全被锁头抵消了。我之前见过一段代码为了修改 ConcurrentDictionary 里的某个 value给整个遍历加了个大锁结果并发请求全堵在锁上改造后直接换TryUpdate吞吐量翻了几倍。4. async/await异步和多线程是两个维度4.1 异步不“开线程”但能“省线程”新手最容易混淆的概念async方法不等于多线程。它跟线程最直接的关系是遇到真正的异步等待时当前线程会被释放回线程池等 IO 完成后再回来继续执行。举个例子从接口读数据用同步的方式写线程会一直阻塞等待响应用await HttpClient.GetStringAsync(...)这个线程就可以先去处理其他请求数据回来后再接着执行。异步的价值在于“等待时不占用人手”而不是把更多人拉进来干活。所以我一直建议写 IO 密集的业务代码用异步方式推进写计算密集的核心算法才考虑并行和线程。前者是“减少线程浪费”后者才是“增加线程并行”。这两类问题的解法完全不同混在一起才是噩梦的开始。4.2 状态机不深挖但这些坑必须知道async/await背后是编译器生成的状态机每次await都会把“接下来要做的事情”注册为一个 continuation。看起来像写同步代码实际执行顺序被拆成了多段。比较需要留意的是同步上下文问题。在 UI 程序或某些自带上下文的环境里await后默认要“回到原来的上下文”。如果在 UI 线程上阻塞等待一个异步任务比如.Result、.GetAwaiter().GetResult()就可能出现“UI 线程在等任务任务又在等回到 UI 线程”的死锁。应对方案有两个一是从最外层就开始异步不把异步方法包在同步等待里二是在库代码里使用ConfigureAwait(false)告诉状态机不要尝试回原来上下文。string content await httpClient.GetStringAsync(url).ConfigureAwait(false);这句话的含义是代码恢复执行时不需要回到调用者的上下文直接在线程池线程上继续即可。这能有效避免 UI / ASP.NET 环境下的隐式死锁但也意味着后续代码不能轻易访问 UI 控件或请求上下文。另外async void要尽量避免。它只在事件处理器里是合理写法其余场景一旦异常抛出来直接变成一个难以捕获的未处理异常。普通方法应该一律返回Task或TaskT。4.3 同步与异步的边界怎么控制在实际项目中我见过很糟糕的“全链路异步”风潮明明是一个快速内存计算偏要await Task.Run再转一圈。这没有好处反而增加了状态机开销和调度延迟。我的经验是方法里如果没有真正的 IO 等待或不可控耗时步骤直接写成同步方法然后在边界处异步化即可。例如 Controller 层调一个同步服务如果服务本身是纯计算就直接返回结果不要刻意await Task.FromResult。只有涉及网络、磁盘、外部接口时异步才值得。说到同步调异步还有个老掉牙但一直在踩的坑不要用Task.Wait()和Task.Result硬等。我接手某 API 时发现大量异步接口都是.Result阻塞的一遇到高并发就线程池饥饿请求超时率飙升。后来统一改成async一路到底问题缓解了 70% 以上。5. 三种常见并发模式与实操记录5.1 生产者 / 消费者模式和 Channel有一类并发问题特别典型一个线程不停产生数据另一个线程负责消费。最自然的方案是队列。.NET 里有ConcurrentQueue和现代异步环境下的Channel。Channel是个好东西它把生产者和消费者的关系描述得很清晰。生产者只管往队列里写消费者只管读两者互不知道对方存在。它是一种“解耦 背压”的设计可以实现限流、削峰。某数据采集服务里我用了有界 Channel 来限制积压量var options new BoundedChannelOptions(1000) { FullMode BoundedChannelFullMode.Wait }; var channel Channel.CreateBoundedOrder(options);生产者使用WriteAsync消费方使用ReadAllAsync循环处理。当队列满时生产方会等待相当于一种“背压机制”防止无界积压拖垮内存。这个设计让生产线上的任务“不慌不忙”比单纯用while (true) { queue.TryDequeue(...) }干净得多。在 .NET Framework 老项目或者不想引入新依赖的情况下BlockingCollection是另一个熟悉的选择它支持有界容量和阻塞操作更偏传统多线程风格。两套工具的选型要点是如果你在写新代码并且能使用较新运行时直接选 Channel如果是在维护老系统BlockingCollection 更顺滑。5.2 CPU 密集计算Parallel 的正确用法如果你有一批计算任务要同时跑完用Parallel.For比手动Task.Run循环更安全。它会自动做分区根据核心数和工作量动态调整并行度并把结果聚合逻辑简化。我写过一段图像批处理逻辑对几千张图片做滤镜计算。直接写循环太慢手动开线程又怕把 CPU 占满于是用Parallel.ForEach加ParallelOptions限制并发度var options new ParallelOptions { MaxDegreeOfParallelism Environment.ProcessorCount / 2 }; Parallel.ForEach(imageList, options, image { ProcessOneImage(image); });这里的限制不是拍脑袋生产环境同一台服务器还会跑其他服务把逻辑核数全占满会影响他人。保留一半核心给 IO 和系统调度整体体验反而更稳。但要注意Parallel适合计算型任务不适合任务里还包了异步 IO 的情况。一旦你在并行循环里Task.Delay或者调用外部 API这个线程在等待时依然被占住线程池的效率就崩了。混合场景应该用Task.WhenAllSemaphoreSlim做一个异步并发池。5.3 分批处理的节奏控制高并发导入这类场景“一次派发所有任务”并不是好主意。一来系统瞬时压力太大二来一旦中途出问题回滚和重试的粒度都很难控制。我在某次的库存同步项目里把任务按批次拆分每批 200 个每批之间留出短暂间隔既保证吞吐又避免连续大量 IO 请求打爆目标系统。简单说就是for (int offset 0; offset total; offset batchSize) { var batch data.Skip(offset).Take(batchSize).ToArray(); var tasks batch.Select(i ProcessItemAsync(i)); await Task.WhenAll(tasks); await Task.Delay(50); // 控制节奏 }这里的 50 毫秒不是省 CPU是给外部系统一个缓冲时间防止限流返回错误后还要重试反而更慢。很多时候“快”不是靠一次全切开出来的而是靠让系统处于不崩溃的稳定状态。6. 排查和避坑实录那些让人想摔键盘的问题6.1 线程开了几百个程序却越来越卡某次我接手一个 Windows 服务内存占用不高但 CPU 持续飙升任务处理速度越来越慢。抓完 dump 一看线程池里几百个线程绝大多数状态是“阻塞等待”。再往里追发现核心逻辑里有大量SemaphoreSlim.Wait()嵌套而信号量初始值太小导致线程互相等待线程池判断“线程不够”继续增加线程结果越加越卡。排查过程可以简单总结为先看是 CPU 高还是线程数高再去 dump 里看线程栈再确认是否有同步等待链。用录dump的方式非常直观几个线程卡在哪一行、等哪个锁对象一目了然。这类问题很少是“线程数不够”而是“不应该阻塞的地方阻塞了”。想办法把阻塞等待换成异步等待或者对关键资源做更合理的并发控制线程数会自然下降性能反而提升。6.2 高并发下偶发数据错乱另一种让人头疼的问题是“运行十次有两次数据不对”。这类 bug 有明显的随机性通常和竞态条件有关。你以为是终于“多线程跑起来了”结果是共享状态被多个线程交替改写最终结果取决于调度顺序。我之前遇到一个订单号生成逻辑在并发下出现重复订单号。最初排查时大家怀疑是数据库唯一索引的问题后来定位到是内存里一个全局计数器被并发自增而读取和1不是原子的。改成Interlocked.Increment后重复问题直接消失。排查竞态条件的实用技巧是给日志加线程 ID 和上下文信息复现时开启详细日志再配合 Visual Studio 的“并行任务”窗口观察各线程的执行位置。如果你能看到两个线程同时进入了同一段代码大概率就是临界区没保护或者锁对象用错了。6.3 性能没升反降的隐形杀手有时候并发改造后性能不仅没提升反而下降。最常见的原因是“任务切得太碎”或“锁的竞争太严重”。一个任务本身只需要 1 毫秒你把它拆成 10 个并行子任务每个子任务还要加锁访问共享集合。结果是并行带来的收益远远小于加锁和上下文切换的代价性能自然不升反降。在评估并发方案时可以先计算理论收益设有 N 个核心任务并行部分占比为 P根据 Amdahl 定律加速比上限是 1 / ((1-P) P/N)。换句话说如果 90% 的时间都在串行更新共享数据结构那么无论如何加线程性能天花板都很低。这也是为什么“锁越少越好”不是口号是架构设计里的硬道理。6.4 几句话版本的排查速查表症状排查方向常见解法线程数疯狂上涨看线程栈是否有阻塞等待把阻塞改为异步 / 调整信号量偶发数据错乱找共享变量读写点加锁、用并发集合或 Interlocked吞吐量上不去看抢锁等待和上下文切换减小锁粒度、分片处理请求偶发超时看线程池爬坡和同步等待预热线程池、异步化链路async 方法卡死看同步上下文依赖去掉 .Result 硬等配置 ConfigureAwait(false)这个表是我每次重构并发代码前都要过一遍的清单能省下很多无效排查时间。写在最后的个人心得我带过几个新手做并发项目发现最容易出问题的不是 API 用错了而是“根本不知道自己写的东西会同时跑多少个实例”。所以我在代码评审里养成了一个习惯每个涉及共享状态的地方都会先问三个问题这里的数据真的需要被多个线程同时改吗等待资源时线程是被阻塞了还是可以去做别的事锁的范围能再缩小一点吗或者干脆消除锁多线程这门功夫单靠“会调 API”走不远真正拉开差距的是对线程成本、锁取舍、任务拆分的理解。你在工程里踩过的每一个死锁、每一次线程池饥饿最后都会变成对并发系统的直觉。这种直觉不是看文档看出来的是真把代码在高负载环境下跑一遍、再把失败现场分析一遍以后攒出来的经验。