多线程这东西C# 里入门容易精通难。我前阵子 review 一个内部服务端的并发模块满眼都是 new Thread 配合 Hashtable 加锁的写法压测一上来 CPU 直接飙到 90% 多吞吐量却上不去。后来改造成 Task Channel 细粒度锁同样机器压测结果翻了一倍多。这一路踩坑下来我觉得有必要把那些编译能过、跑起来就炸的问题系统整理一下。这篇会持续更新每一条都是我或者身边同事在真实项目里撞过的墙涉及线程选型、锁粒度、async/await 边界、取消机制、并发容器和死锁排查希望能帮你少走点弯路。1. 别急着 new Thread线程创建的选型与生命周期1.1 为什么我不推荐业务代码里 new Thread很多刚接触多线程的开发者第一反应是 Thread t new Thread(MyMethod); t.Start();。这个写法在桌面小程序里没问题但在服务端或者高并发场景里每 new 一个 Thread 都意味着分配约 1MB 的栈空间还要走一遍系统内核对象的创建和销毁流程。线程一多光上下文切换就能吃掉大量 CPU 时间片。我见过一个数据同步服务每隔几分钟就创建几十个独立线程跑任务任务结束后没 Join 也没复用结果线程像潮水一样来来回回线程切换开销占比一度超过 40%。更麻烦的是new Thread 的线程难以管理生命周期。线程执行完就销毁中途抛异常如果没有全局处理整个进程都可能受影响。你没法方便地拿到线程的运行结果也没办法优雅地取消它。想做到这个任务 5 分钟跑不完就取消用裸 Thread 实现要费很大劲还要自己写轮询标志位。1.2 ThreadPool、Task 和 Thread 的本质差别ThreadPool 解决了线程复用的问题。CLR 底层会维护一个线程池池里的线程执行完一个任务后不会立刻销毁而是回到池里等待下一个任务。这样避免了反复创建销毁的损耗。但是 ThreadPool 也有自己的毛病它的队列是全局的如果你的任务里混着耗时长的 IO 操作和短小的计算任务长任务会堵住队列里的短任务同时 ThreadPool 动态调整线程数有延迟突发流量一上来最初一瞬间任务会排队等待线程分配。Task 是更高级的抽象它默认调度到 ThreadPool 上执行但提供了远比 Thread 丰富的 API。你可以用 Task.WhenAll 等待多个任务可以用 Task.Run 显式启动一个新任务也可以通过 await 拿到异步结果。我通常把 Task 和 Thread 类比成工作计划和雇来干活的工人Task 描述你要做什么Thread 是真正的工人而 ThreadPool 是工头手里的工人池。业务代码里你应该面向 Task 编程让调度器帮你决定用哪个工人。1.3 线程生命周期里最容易忽视的后台线程与线程名用 Thread 类的时候有一个 IsBackground 属性值得特别留意。默认 IsBackground 为 false说明这个线程是前台线程。前台线程有个特点只要进程中还有前台线程存活进程就不会退出。如果你的窗口程序里 start 了一个前台线程关闭主窗口时进程会假死任务管理器里还能看到进程但界面已经关了——因为那个前台线程还在跑循环。把这个线程设为 IsBackground true进程才会在所有前台线程退出后强制结束后台线程。不过后台线程的缺点是进程退出时它会被直接掐断如果线程里正在写文件可能导致文件损坏。还有一个小习惯建议给线程或者 Task 起名字。Thread.Name 属性可以方便你在调试器的线程窗口里一眼认出这是负责下载的线程那是处理消息的线程。对于 Task没有直接 Name但你可以在开始时用 Thread.CurrentThread.Name 赋值或者用 AsyncLocal 传一个逻辑上下文名字。之前排查某个服务卡死我打开线程窗口清一色的Worker Thread根本分不清谁是谁最后靠给线程命名才快速定位到阻塞的那条链路。这些小习惯在出问题的时候能省下大量时间。2. 共享数据的锁粒度、性能和那点自以为安全2.1 lock 的本质与实例锁/静态锁的坑lock 语句是 C# 里最常用的同步原语它其实就是 Monitor.Enter / Monitor.Exit 的语法糖。很多人只记住了访问共享变量前加锁但忘了锁对象的选择会直接影响安全边界。最常见的坑是 lock(this)。如果你在类的实例方法里写了 lock(this)而外部代码也可能拿到同一个实例对象去 lock那么两个完全不相关的方法会因为锁对象被外部锁占用而互相阻塞。更糟糕的是如果这个实例被序列化或者被其他代码作为锁对象使用很容易出现意外死锁。所以锁对象应该是一个独立的、私有的、专门用来同步的对象比如 private readonly object _locker new object();。另一个经典坑是把 lock 对象声明成 public static。我见过某项目里写了一个 public static readonly object GlobalLock结果所有模块都拿它做锁整个系统的所有共享资源全部串行化并发度直接归零。锁对象的作用范围要尽可能小锁的粒度要跟着业务走而不是全局一把锁。2.2 lock 范围太大带来的性能泥潭很多人写多线程代码第一反应是把整个方法体都包进 lock 里。比如读取某个缓存的时候先 lock然后读字典接着反序列化再对结果做计算最后返回——整个流程串起来可能几十毫秒。几十毫秒看起来不长但如果有 1000 个线程同时进来抢这把锁其他人的等待时间就是 1000 乘以平均持锁时间系统吞吐量自然上不去。正确的做法是缩小锁范围只保护真正会被并发修改的临界资源访问比如对字典的单次读取或者写入而不是保护后面的计算逻辑。像先读缓存再判断再写入这种复合操作可能需要锁但你可以把里面的耗时操作拆出去。举个例子更新一个用户积分时如果你把读取当前积分 - 计算新积分 - 写回包在同一个锁里没问题但千万别把数据库读操作也放进去。IO 操作应该在锁外先拿到数据再在锁内只做内存中的变量更新。这里有一个取舍如果必须保证读后写的一致性可以考虑用 ConcurrentDictionary 的原子方法或者用 Interlocked 做累加而不是一把大锁包住所有东西。2.3 volatile、Interlocked 和内存屏障够用但别滥用volatile 关键字是很多面试题里的常客但实际业务里它的适用范围极窄。volatile 告诉编译器这个字段可能被多个线程修改不要对它做寄存器缓存优化每次读写都从内存里走。它只对特定类型有效比如 int、bool、引用类型而且它不能保证原子性。你写 if (flag) { ... } 和 flag true 这样的是安全的但如果你做 count 这种操作volatile 一点用都没有因为 count 在底层是读-改-写三步多个线程同时执行会互相覆盖。真正适合做计数累加的是 Interlocked.Increment / Interlocked.Add 这类原子操作。它们直接映射到 CPU 的原子指令不需要锁性能比 lock 高很多。而且 Interlocked 还提供了类似 MemoryBarrier 的效果保证内存可见性。但 Interlocked 也有局限它只能操作一个共享变量如果你需要保护多个变量之间的逻辑一致性比如A 和 B 必须同时更新那就得回到锁或者使用不可变对象。内存屏障是一个底层概念C# 里很少需要手动用 Thread.MemoryBarrier()。你只要记住一个原则跨线程共享可变数据时一定要用 lock、Interlocked 或者合适的并发容器而不是依赖某个字段碰巧可见。Monitor 和 lock 内部已经插入了必要的内存屏障保证锁内的写操作在锁外的读操作之前可见。与其研究底层 CPU 缓存一致性不如老老实实把数据访问的边界梳理清楚。3. async/await 不等于多线程上下文切换与 SynchronizationContext3.1 异步方法里的代码跑在哪个线程很多初学者把 async/await 和多线程画等号其实这是两个维度的东西。async/await 解决的是异步操作的流程控制它本身不创建新线程。一个 async 方法在 await 到 IO 完成信号之前执行它的线程会回到线程池或者调用者那里等到 IO 完成后方法继续执行。整个过程可能根本没有额外的线程被创建。举个例子你在 UI 线程里写了 await Task.Delay(1000)UI 线程不会被阻塞方法在 Delay 结束后的延续会回到 UI 线程。但在控制台应用里没有 SynchronizationContextawait 后的延续会跑到线程池线程上这就是为什么不同环境下线程 ID 可能不一样。理解了这个你就能明白为什么有些代码在 UI 程序里没问题放到服务端却出现线程跳变。3.2 ConfigureAwait 到底要不要加这是一个跟多线程关系很大的问题。一般在服务端代码里默认情况下 await 之后编译器会尝试捕获当前的 SynchronizationContext 并回到那个上下文。在 ASP.NET Core 里SynchronizationContext 默认是空的所以配置上下文的影响相对小。但在老式的 .NET Framework WebForms、WPF、WinForms 里捕获的 UI 上下文会让延续回到 UI 线程这意味着如果一个库方法 await 了一个网络请求它后续几十毫秒的执行都在 UI 线程上进行UI 可能卡顿。如果你在写一个类库里面的内部 await 不需要回到 UI 线程就应该用 ConfigureAwait(false) 告诉运行时别帮我切上下文继续在线程池线程上跑就行。这样能减少上下文切换的开销。但要注意如果你真的需要在 await 之后访问 UI 控件那就别用 ConfigureAwait(false)。一个常见的坑是在一个 async 事件处理器里 await 一个第三方方法第三方方法内部用了 ConfigureAwait(false)导致延续跑到了线程池线程然后你在这个延续里访问 UI 控件直接抛异常。所以我的原则是业务外层的 UI 代码保持上下文捕获库内部、服务端内部的代码尽量 ConfigureAwait(false)。3.3 误用 Task.Run 包装异步 IO 的双重浪费有一种让我特别无语的写法await Task.Run(() HttpClient.GetAsync(url))。Task.Run 的作用是把一个同步委托扔到线程池线程上去跑而 HttpClient.GetAsync 本身就是异步方法它内部的等待不会占用线程池线程。你用 Task.Run 包一层白白多调度了一个线程池线程同时还让 GetAsync 的异步状态机跑在那个线程上——虽然 GetAsync 执行到第一个 await 会立刻释放线程但这个调度开销毫无意义。正确的做法是直接 await HttpClient.GetAsync(url)它天然异步IO 等待期间没有线程被占用。类似的还有 await Task.Run(() File.ReadAllTextAsync(...))同样是多余包装。如果你有一个真正 CPU 密集型的同步操作比如计算哈希或者图像处理才值得用 Task.Run 把它扔到后台线程避免阻塞 UI 线程。判断标准很简单操作主要是 IO 等待还是 CPU 计算IO 等待直接 await 对应异步方法CPU 计算才用 Task.Run。4. 协作式取消与超时CancellationToken 的正确打开方式4.1 为什么我坚持每个 Task 循环里都要 Poll多线程任务最常见的需求是跑一会儿如果用户取消了就停下来。很多人会用一种简单粗暴的写法用一个静态 bool 变量 IsCancelled线程循环里判断它然后主线程把 IsCancelled 置为 true。这个方案在简单场景下能跑但有很多毛病bool 变量没有内存屏障保证另一个线程的修改可能延迟可见而且你无法在 Task 框架层面配合取消比如 Task.WaitAsync 的超时取消、Task.WhenAll 的集体取消都参与不了。正确的姿势是 CancellationTokenSource.Cancel()然后在线程的循环里调用 token.ThrowIfCancellationRequested() 或者判断 token.IsCancellationRequested。CancellationToken 内部包含了高效的信号机制和内存屏障保证。每一次循环轮询这个 token 的开销极低但它给了你一个统一的取消入口。你可以把同一个 token 传给所有子任务Cancel 的时候所有任务都会收到信号。4.2 取消回调里的危险操作与资源释放CancellationToken.Register 可以注册一个取消时执行的回调。这个回调有个陷阱它是在调用 Cancel 的线程上同步执行的。如果 Cancel 方法被 UI 线程调用而回调里写了一个耗时操作那么 UI 会卡住。更危险的是如果回调里访问了某个已经被释放的资源比如 HttpClient 已经 Dispose 了那就可能抛 ObjectDisposedException。所以注册回调时要注意回调应该轻量、快速只做必要的状态标记和清理不要做复杂逻辑。如果你需要等待多个任务完成后再统一清理资源更好的做法是把清理逻辑放在 finally 块里配合 CancellationToken 的 WaitHandle 使用。还有一种常见场景是超时即取消你希望一个任务在 3 秒内没完成就取消它于是写 var cts new CancellationTokenSource(TimeSpan.FromSeconds(3));。此时如果任务中途抛了 OperationCanceledException你要判断是外部主动取消还是超时取消。可以用 cts.IsCancellationRequested 结合定时器区分但更可靠的是看 token 的取消原因或者用不同的 token 区分两种场景。4.3 超时不是简单的 Thread.Sleep 判断很多人的超时实现是这样的Thread.Sleep(3000); if (flag false) { 失败 }。这个方案有一个致命问题它不是在等待任务完成或超时而是不管任务是否完成先睡 3 秒再看结果。如果任务 100 毫秒就完成了你要多等 2.9 秒如果任务需要 5 秒你在 3 秒的时候只是探测了一下任务还在后台跑你根本无法中止它也无法确认它的最终状态。正确的超时等待应该用 Task.WhenAny(task, Task.Delay(timeout, token))。如果 WhenAny 返回的是 Delay 任务说明超时了此时你可以选择取消这个 task 的 token或者至少知道它没有及时完成。这里要特别小心WhenAny 返回后原来的 task 可能还在继续执行不要以为 timeout 了就自动中止了。你需要给那个 task 传入同一个 CancellationToken让超时后 Cancel 信号能终止它。5. 并发容器与信号量选对工具少踩坑5.1 Dictionary 加锁 vs ConcurrentDictionary 的取舍我见过太多人不管什么场景只要看到字典就无脑 Dictionary lock。实际上 .NET 提供了一整套线程安全集合其中 ConcurrentDictionary 在绝大多数场景下都比Dictionary 锁表现更好。为什么因为 ConcurrentDictionary 内部做了分段锁或者细粒度锁不同线程操作不同的桶时可以并行执行而普通 Dictionary 配一把大锁就全串行了。但 ConcurrentDictionary 也不一定总是最优。如果你几乎只有写入操作而且对顺序不敏感ConcurrentDictionary 没问题。如果读多写少而且字典数据量很大ConcurrentDictionary 的读操作为了支持并发修改内部需要额外的可见性开销有时候普通 Dictionary 加 ReaderWriterLockSlim 反而更快。关键是你要用工具真实压测而不是凭感觉选。还有一个常见误区ConcurrentDictionary 的方法比如 TryGetValue、AddOrUpdate 确实是原子的但它不能保证跨多个方法的复合操作原子性比如先 TryGetValue 判断 key 不存在再 Add这两步之间其他线程可能插进来。如果你需要不存在则添加存在则更新这种原子语义请直接用 GetOrAdd 或者 AddOrUpdate而不是自己拼多个步骤。5.2 BlockingCollection 的生产者消费者与 CompleteAdding 时机生产者消费者模式最经典的工具是 BlockingCollection 它内部封装了一个线程安全的队列默认是 ConcurrentQueue。生产者可以 Add 数据消费者通过 GetConsumingEnumerable 在后台线程里逐个取数据。这个模式在日志写入、任务分发、消息处理里都非常好用。但有几个坑第一个坑是 CompleteAdding 的时机。如果生产者还没来得及把缓冲区的数据全部 Add 完就调用了 CompleteAdding那么消费者会提前把已有数据消费完然后退出剩下没来得及进入队列的数据就丢了。所以完整的流程应该是所有生产者都完成了 Add 之后再调用 CompleteAdding。如果你有多个生产者你得确保每个生产者都结束自己的添加逻辑后最后统一调用一次 CompleteAdding而不是每个生产者各自调用一次就完事。多次调用 CompleteAdding 会抛异常所以要用一个标志量保证只调用一次。第二个坑是消费者的异常处理。GetConsumingEnumerable 在迭代时如果底层队列没有数据会阻塞直到有数据或者 CompleteAdding 被调用。你需要在循环里对单个元素做 try/catch否则一个元素处理异常会让整个消费者线程挂掉。5.3 SemaphoreSlim 与异步锁的差别semaphore 是控制并发数量的信号量。在 C# 里SemaphoreSlim 支持异步等待await semaphore.WaitAsync()这个动作不会阻塞线程。而 lock / Monitor 必须是同步代码块里使用你不可能在 await 表达式里锁住一个 Monitor严格说可以但容易造成死锁。所以当你需要限制异步代码的并发度时SemaphoreSlim 是首选。一个典型场景你需要同时最多允许 5 个任务访问某个外部 API避免被打爆。你可以 new SemaphoreSlim(5)然后在每个工作任务里 await WaitAsync()做完了 Release()。这里要注意WaitAsync 之后如果任务中途抛异常你必须在 finally 里 Release()否则信号量一直少一个最后所有任务都会被挡住。还有一个区分SemaphoreSlim 和异步锁是两个东西。异步锁指的是比如一个基于 SemaphoreSlim 实现的 LockAsync 方法它可以保护一个异步操作不并发执行但锁本身不是跨线程的所有权而是基于等待队列。如果你需要某个资源在多线程下只能同时一个线程访问用 lock 就够了如果你需要多个异步任务同时只有一个能进入某段代码用 SemaphoreSlim WaitAsync 的组合。别用 lock 去包一个大段 await那会带来真正的死锁风险。6. 从一次死锁说起排查思路与复现技巧6.1 死锁的经典四条件与一次模拟事故死锁是高并发项目里最头疼的问题。它的四条件是互斥、持有并等待、不可剥夺、循环等待。这四个条件缺一不可。C# 里最常见的是两个线程以不同顺序获取两把锁导致互相等待。我模拟过一个经典场景线程 A 先拿锁1再等锁2线程 B 先拿锁2再等锁1两边都卡住了。现实中这种问题可能隐藏很深因为锁的获取往往嵌套在多个方法之间。很多死锁不是一开始就出现的而是某个时间点并发量上来了比如双十一秒杀场景某个线程执行慢了另一个线程在等待时新增了一个嵌套锁调用然后死锁概率从 0.001% 上升到 10%压测就暴露了。这就是为什么我在写代码时非常强调锁的顺序统一如果两个资源总是以同样的顺序获取循环等待条件就能被打破。比如所有需要多个锁的路径都按锁1 再锁2的顺序来那就不可能循环。6.2 怎么快速定位死锁现场定位死锁最常见的方式是抓 dump。在 Windows 上可以任务管理器右键进程创建转储文件在 Linux 上用 dotnet-dump 命令。拿到 dump 之后用 dotnet-sos 的 threads 命令和 clrstack 命令查看每个线程的托管调用栈。死锁现场最典型的特征是两个线程的栈分别停在 Monitor.Enter 或者 WaitHandle.WaitOne 上而且它们的指令指向的锁对象 ID 能对应上。另外你可以用超时 日志的手段提前发现死锁。比如把 lock 语句替换成 Monitor.TryEnter(obj, TimeSpan.FromSeconds(2))返回 false 说明 2 秒内没拿到锁记一条日志。这个改动对性能影响不大但能让你在死锁即将发生的时候看到警告。我见过某团队的定时任务系统就是这样加了超时日志后每次慢操作都能自动告警而不是等到客户投诉。6.3 事后处理超时、顺序与异常恢复死锁发生后靠人工重启服务只是治标。你要做的第一件事是修复代码里锁顺序不一致的问题。如果实在改不动可以用锁超时来兜底Monitor.TryEnter 超时后抛异常或者记日志至少让调用方有机会恢复。另一个办法是减少持锁时间把不必要的代码移出临界区。还有一点容易被忽略死锁往往伴随着线程池耗尽。当线程池线程被死锁全部占用后续的 Task 排队等待现象就是 CPU 不高但请求全部超时。这时候你要监控线程池的状态比如记录 ThreadPool.ThreadCount 的数量超过某个阈值就要告警。除了死锁还要小心活锁和饥饿。活锁是线程一直重试但没有进展比如拿不到锁就无限重试然后释放又重试。饥饿是某个低优先级线程一直等不到资源。这些看起来和死锁相似但现象不同处理方式也不同。我把这套排查思路整理成了一个小清单先确认线程栈是否都在等待锁再检查锁顺序是否统一然后看持锁时间是否过长最后验证是否线程池耗尽。大多数并发问题都能在这四步里找到答案。踩过这么多坑之后我最大的体会是多线程实现本身并不难难的是在复杂业务里做到既安全又高效。每次代码审查的时候我都会下意识问几个问题这个共享资源能不能用并发容器代替锁这个 lock 块是不是可以再小一点这个 await 后面有没有必要捕获上下文取消逻辑有没有渗透到所有循环里这些问题问多了写出来的代码自然就稳了。这篇文章先更新到这里后续我要是再撞上新的并发难题会继续补进来。 
长河君 · 2026/10/18 15:26:28 · 阅读 1.2k C#多线程并发实战：从锁粒度、async/await到死锁排查
多线程这东西C# 里入门容易精通难。我前阵子 review 一个内部服务端的并发模块满眼都是 new Thread 配合 Hashtable 加锁的写法压测一上来 CPU 直接飙到 90% 多吞吐量却上不去。后来改造成 Task Channel 细粒度锁同样机器压测结果翻了一倍多。这一路踩坑下来我觉得有必要把那些编译能过、跑起来就炸的问题系统整理一下。这篇会持续更新每一条都是我或者身边同事在真实项目里撞过的墙涉及线程选型、锁粒度、async/await 边界、取消机制、并发容器和死锁排查希望能帮你少走点弯路。1. 别急着 new Thread线程创建的选型与生命周期1.1 为什么我不推荐业务代码里 new Thread很多刚接触多线程的开发者第一反应是 Thread t new Thread(MyMethod); t.Start();。这个写法在桌面小程序里没问题但在服务端或者高并发场景里每 new 一个 Thread 都意味着分配约 1MB 的栈空间还要走一遍系统内核对象的创建和销毁流程。线程一多光上下文切换就能吃掉大量 CPU 时间片。我见过一个数据同步服务每隔几分钟就创建几十个独立线程跑任务任务结束后没 Join 也没复用结果线程像潮水一样来来回回线程切换开销占比一度超过 40%。更麻烦的是new Thread 的线程难以管理生命周期。线程执行完就销毁中途抛异常如果没有全局处理整个进程都可能受影响。你没法方便地拿到线程的运行结果也没办法优雅地取消它。想做到这个任务 5 分钟跑不完就取消用裸 Thread 实现要费很大劲还要自己写轮询标志位。1.2 ThreadPool、Task 和 Thread 的本质差别ThreadPool 解决了线程复用的问题。CLR 底层会维护一个线程池池里的线程执行完一个任务后不会立刻销毁而是回到池里等待下一个任务。这样避免了反复创建销毁的损耗。但是 ThreadPool 也有自己的毛病它的队列是全局的如果你的任务里混着耗时长的 IO 操作和短小的计算任务长任务会堵住队列里的短任务同时 ThreadPool 动态调整线程数有延迟突发流量一上来最初一瞬间任务会排队等待线程分配。Task 是更高级的抽象它默认调度到 ThreadPool 上执行但提供了远比 Thread 丰富的 API。你可以用 Task.WhenAll 等待多个任务可以用 Task.Run 显式启动一个新任务也可以通过 await 拿到异步结果。我通常把 Task 和 Thread 类比成工作计划和雇来干活的工人Task 描述你要做什么Thread 是真正的工人而 ThreadPool 是工头手里的工人池。业务代码里你应该面向 Task 编程让调度器帮你决定用哪个工人。1.3 线程生命周期里最容易忽视的后台线程与线程名用 Thread 类的时候有一个 IsBackground 属性值得特别留意。默认 IsBackground 为 false说明这个线程是前台线程。前台线程有个特点只要进程中还有前台线程存活进程就不会退出。如果你的窗口程序里 start 了一个前台线程关闭主窗口时进程会假死任务管理器里还能看到进程但界面已经关了——因为那个前台线程还在跑循环。把这个线程设为 IsBackground true进程才会在所有前台线程退出后强制结束后台线程。不过后台线程的缺点是进程退出时它会被直接掐断如果线程里正在写文件可能导致文件损坏。还有一个小习惯建议给线程或者 Task 起名字。Thread.Name 属性可以方便你在调试器的线程窗口里一眼认出这是负责下载的线程那是处理消息的线程。对于 Task没有直接 Name但你可以在开始时用 Thread.CurrentThread.Name 赋值或者用 AsyncLocal 传一个逻辑上下文名字。之前排查某个服务卡死我打开线程窗口清一色的Worker Thread根本分不清谁是谁最后靠给线程命名才快速定位到阻塞的那条链路。这些小习惯在出问题的时候能省下大量时间。2. 共享数据的锁粒度、性能和那点自以为安全2.1 lock 的本质与实例锁/静态锁的坑lock 语句是 C# 里最常用的同步原语它其实就是 Monitor.Enter / Monitor.Exit 的语法糖。很多人只记住了访问共享变量前加锁但忘了锁对象的选择会直接影响安全边界。最常见的坑是 lock(this)。如果你在类的实例方法里写了 lock(this)而外部代码也可能拿到同一个实例对象去 lock那么两个完全不相关的方法会因为锁对象被外部锁占用而互相阻塞。更糟糕的是如果这个实例被序列化或者被其他代码作为锁对象使用很容易出现意外死锁。所以锁对象应该是一个独立的、私有的、专门用来同步的对象比如 private readonly object _locker new object();。另一个经典坑是把 lock 对象声明成 public static。我见过某项目里写了一个 public static readonly object GlobalLock结果所有模块都拿它做锁整个系统的所有共享资源全部串行化并发度直接归零。锁对象的作用范围要尽可能小锁的粒度要跟着业务走而不是全局一把锁。2.2 lock 范围太大带来的性能泥潭很多人写多线程代码第一反应是把整个方法体都包进 lock 里。比如读取某个缓存的时候先 lock然后读字典接着反序列化再对结果做计算最后返回——整个流程串起来可能几十毫秒。几十毫秒看起来不长但如果有 1000 个线程同时进来抢这把锁其他人的等待时间就是 1000 乘以平均持锁时间系统吞吐量自然上不去。正确的做法是缩小锁范围只保护真正会被并发修改的临界资源访问比如对字典的单次读取或者写入而不是保护后面的计算逻辑。像先读缓存再判断再写入这种复合操作可能需要锁但你可以把里面的耗时操作拆出去。举个例子更新一个用户积分时如果你把读取当前积分 - 计算新积分 - 写回包在同一个锁里没问题但千万别把数据库读操作也放进去。IO 操作应该在锁外先拿到数据再在锁内只做内存中的变量更新。这里有一个取舍如果必须保证读后写的一致性可以考虑用 ConcurrentDictionary 的原子方法或者用 Interlocked 做累加而不是一把大锁包住所有东西。2.3 volatile、Interlocked 和内存屏障够用但别滥用volatile 关键字是很多面试题里的常客但实际业务里它的适用范围极窄。volatile 告诉编译器这个字段可能被多个线程修改不要对它做寄存器缓存优化每次读写都从内存里走。它只对特定类型有效比如 int、bool、引用类型而且它不能保证原子性。你写 if (flag) { ... } 和 flag true 这样的是安全的但如果你做 count 这种操作volatile 一点用都没有因为 count 在底层是读-改-写三步多个线程同时执行会互相覆盖。真正适合做计数累加的是 Interlocked.Increment / Interlocked.Add 这类原子操作。它们直接映射到 CPU 的原子指令不需要锁性能比 lock 高很多。而且 Interlocked 还提供了类似 MemoryBarrier 的效果保证内存可见性。但 Interlocked 也有局限它只能操作一个共享变量如果你需要保护多个变量之间的逻辑一致性比如A 和 B 必须同时更新那就得回到锁或者使用不可变对象。内存屏障是一个底层概念C# 里很少需要手动用 Thread.MemoryBarrier()。你只要记住一个原则跨线程共享可变数据时一定要用 lock、Interlocked 或者合适的并发容器而不是依赖某个字段碰巧可见。Monitor 和 lock 内部已经插入了必要的内存屏障保证锁内的写操作在锁外的读操作之前可见。与其研究底层 CPU 缓存一致性不如老老实实把数据访问的边界梳理清楚。3. async/await 不等于多线程上下文切换与 SynchronizationContext3.1 异步方法里的代码跑在哪个线程很多初学者把 async/await 和多线程画等号其实这是两个维度的东西。async/await 解决的是异步操作的流程控制它本身不创建新线程。一个 async 方法在 await 到 IO 完成信号之前执行它的线程会回到线程池或者调用者那里等到 IO 完成后方法继续执行。整个过程可能根本没有额外的线程被创建。举个例子你在 UI 线程里写了 await Task.Delay(1000)UI 线程不会被阻塞方法在 Delay 结束后的延续会回到 UI 线程。但在控制台应用里没有 SynchronizationContextawait 后的延续会跑到线程池线程上这就是为什么不同环境下线程 ID 可能不一样。理解了这个你就能明白为什么有些代码在 UI 程序里没问题放到服务端却出现线程跳变。3.2 ConfigureAwait 到底要不要加这是一个跟多线程关系很大的问题。一般在服务端代码里默认情况下 await 之后编译器会尝试捕获当前的 SynchronizationContext 并回到那个上下文。在 ASP.NET Core 里SynchronizationContext 默认是空的所以配置上下文的影响相对小。但在老式的 .NET Framework WebForms、WPF、WinForms 里捕获的 UI 上下文会让延续回到 UI 线程这意味着如果一个库方法 await 了一个网络请求它后续几十毫秒的执行都在 UI 线程上进行UI 可能卡顿。如果你在写一个类库里面的内部 await 不需要回到 UI 线程就应该用 ConfigureAwait(false) 告诉运行时别帮我切上下文继续在线程池线程上跑就行。这样能减少上下文切换的开销。但要注意如果你真的需要在 await 之后访问 UI 控件那就别用 ConfigureAwait(false)。一个常见的坑是在一个 async 事件处理器里 await 一个第三方方法第三方方法内部用了 ConfigureAwait(false)导致延续跑到了线程池线程然后你在这个延续里访问 UI 控件直接抛异常。所以我的原则是业务外层的 UI 代码保持上下文捕获库内部、服务端内部的代码尽量 ConfigureAwait(false)。3.3 误用 Task.Run 包装异步 IO 的双重浪费有一种让我特别无语的写法await Task.Run(() HttpClient.GetAsync(url))。Task.Run 的作用是把一个同步委托扔到线程池线程上去跑而 HttpClient.GetAsync 本身就是异步方法它内部的等待不会占用线程池线程。你用 Task.Run 包一层白白多调度了一个线程池线程同时还让 GetAsync 的异步状态机跑在那个线程上——虽然 GetAsync 执行到第一个 await 会立刻释放线程但这个调度开销毫无意义。正确的做法是直接 await HttpClient.GetAsync(url)它天然异步IO 等待期间没有线程被占用。类似的还有 await Task.Run(() File.ReadAllTextAsync(...))同样是多余包装。如果你有一个真正 CPU 密集型的同步操作比如计算哈希或者图像处理才值得用 Task.Run 把它扔到后台线程避免阻塞 UI 线程。判断标准很简单操作主要是 IO 等待还是 CPU 计算IO 等待直接 await 对应异步方法CPU 计算才用 Task.Run。4. 协作式取消与超时CancellationToken 的正确打开方式4.1 为什么我坚持每个 Task 循环里都要 Poll多线程任务最常见的需求是跑一会儿如果用户取消了就停下来。很多人会用一种简单粗暴的写法用一个静态 bool 变量 IsCancelled线程循环里判断它然后主线程把 IsCancelled 置为 true。这个方案在简单场景下能跑但有很多毛病bool 变量没有内存屏障保证另一个线程的修改可能延迟可见而且你无法在 Task 框架层面配合取消比如 Task.WaitAsync 的超时取消、Task.WhenAll 的集体取消都参与不了。正确的姿势是 CancellationTokenSource.Cancel()然后在线程的循环里调用 token.ThrowIfCancellationRequested() 或者判断 token.IsCancellationRequested。CancellationToken 内部包含了高效的信号机制和内存屏障保证。每一次循环轮询这个 token 的开销极低但它给了你一个统一的取消入口。你可以把同一个 token 传给所有子任务Cancel 的时候所有任务都会收到信号。4.2 取消回调里的危险操作与资源释放CancellationToken.Register 可以注册一个取消时执行的回调。这个回调有个陷阱它是在调用 Cancel 的线程上同步执行的。如果 Cancel 方法被 UI 线程调用而回调里写了一个耗时操作那么 UI 会卡住。更危险的是如果回调里访问了某个已经被释放的资源比如 HttpClient 已经 Dispose 了那就可能抛 ObjectDisposedException。所以注册回调时要注意回调应该轻量、快速只做必要的状态标记和清理不要做复杂逻辑。如果你需要等待多个任务完成后再统一清理资源更好的做法是把清理逻辑放在 finally 块里配合 CancellationToken 的 WaitHandle 使用。还有一种常见场景是超时即取消你希望一个任务在 3 秒内没完成就取消它于是写 var cts new CancellationTokenSource(TimeSpan.FromSeconds(3));。此时如果任务中途抛了 OperationCanceledException你要判断是外部主动取消还是超时取消。可以用 cts.IsCancellationRequested 结合定时器区分但更可靠的是看 token 的取消原因或者用不同的 token 区分两种场景。4.3 超时不是简单的 Thread.Sleep 判断很多人的超时实现是这样的Thread.Sleep(3000); if (flag false) { 失败 }。这个方案有一个致命问题它不是在等待任务完成或超时而是不管任务是否完成先睡 3 秒再看结果。如果任务 100 毫秒就完成了你要多等 2.9 秒如果任务需要 5 秒你在 3 秒的时候只是探测了一下任务还在后台跑你根本无法中止它也无法确认它的最终状态。正确的超时等待应该用 Task.WhenAny(task, Task.Delay(timeout, token))。如果 WhenAny 返回的是 Delay 任务说明超时了此时你可以选择取消这个 task 的 token或者至少知道它没有及时完成。这里要特别小心WhenAny 返回后原来的 task 可能还在继续执行不要以为 timeout 了就自动中止了。你需要给那个 task 传入同一个 CancellationToken让超时后 Cancel 信号能终止它。5. 并发容器与信号量选对工具少踩坑5.1 Dictionary 加锁 vs ConcurrentDictionary 的取舍我见过太多人不管什么场景只要看到字典就无脑 Dictionary lock。实际上 .NET 提供了一整套线程安全集合其中 ConcurrentDictionary 在绝大多数场景下都比Dictionary 锁表现更好。为什么因为 ConcurrentDictionary 内部做了分段锁或者细粒度锁不同线程操作不同的桶时可以并行执行而普通 Dictionary 配一把大锁就全串行了。但 ConcurrentDictionary 也不一定总是最优。如果你几乎只有写入操作而且对顺序不敏感ConcurrentDictionary 没问题。如果读多写少而且字典数据量很大ConcurrentDictionary 的读操作为了支持并发修改内部需要额外的可见性开销有时候普通 Dictionary 加 ReaderWriterLockSlim 反而更快。关键是你要用工具真实压测而不是凭感觉选。还有一个常见误区ConcurrentDictionary 的方法比如 TryGetValue、AddOrUpdate 确实是原子的但它不能保证跨多个方法的复合操作原子性比如先 TryGetValue 判断 key 不存在再 Add这两步之间其他线程可能插进来。如果你需要不存在则添加存在则更新这种原子语义请直接用 GetOrAdd 或者 AddOrUpdate而不是自己拼多个步骤。5.2 BlockingCollection 的生产者消费者与 CompleteAdding 时机生产者消费者模式最经典的工具是 BlockingCollection 它内部封装了一个线程安全的队列默认是 ConcurrentQueue。生产者可以 Add 数据消费者通过 GetConsumingEnumerable 在后台线程里逐个取数据。这个模式在日志写入、任务分发、消息处理里都非常好用。但有几个坑第一个坑是 CompleteAdding 的时机。如果生产者还没来得及把缓冲区的数据全部 Add 完就调用了 CompleteAdding那么消费者会提前把已有数据消费完然后退出剩下没来得及进入队列的数据就丢了。所以完整的流程应该是所有生产者都完成了 Add 之后再调用 CompleteAdding。如果你有多个生产者你得确保每个生产者都结束自己的添加逻辑后最后统一调用一次 CompleteAdding而不是每个生产者各自调用一次就完事。多次调用 CompleteAdding 会抛异常所以要用一个标志量保证只调用一次。第二个坑是消费者的异常处理。GetConsumingEnumerable 在迭代时如果底层队列没有数据会阻塞直到有数据或者 CompleteAdding 被调用。你需要在循环里对单个元素做 try/catch否则一个元素处理异常会让整个消费者线程挂掉。5.3 SemaphoreSlim 与异步锁的差别semaphore 是控制并发数量的信号量。在 C# 里SemaphoreSlim 支持异步等待await semaphore.WaitAsync()这个动作不会阻塞线程。而 lock / Monitor 必须是同步代码块里使用你不可能在 await 表达式里锁住一个 Monitor严格说可以但容易造成死锁。所以当你需要限制异步代码的并发度时SemaphoreSlim 是首选。一个典型场景你需要同时最多允许 5 个任务访问某个外部 API避免被打爆。你可以 new SemaphoreSlim(5)然后在每个工作任务里 await WaitAsync()做完了 Release()。这里要注意WaitAsync 之后如果任务中途抛异常你必须在 finally 里 Release()否则信号量一直少一个最后所有任务都会被挡住。还有一个区分SemaphoreSlim 和异步锁是两个东西。异步锁指的是比如一个基于 SemaphoreSlim 实现的 LockAsync 方法它可以保护一个异步操作不并发执行但锁本身不是跨线程的所有权而是基于等待队列。如果你需要某个资源在多线程下只能同时一个线程访问用 lock 就够了如果你需要多个异步任务同时只有一个能进入某段代码用 SemaphoreSlim WaitAsync 的组合。别用 lock 去包一个大段 await那会带来真正的死锁风险。6. 从一次死锁说起排查思路与复现技巧6.1 死锁的经典四条件与一次模拟事故死锁是高并发项目里最头疼的问题。它的四条件是互斥、持有并等待、不可剥夺、循环等待。这四个条件缺一不可。C# 里最常见的是两个线程以不同顺序获取两把锁导致互相等待。我模拟过一个经典场景线程 A 先拿锁1再等锁2线程 B 先拿锁2再等锁1两边都卡住了。现实中这种问题可能隐藏很深因为锁的获取往往嵌套在多个方法之间。很多死锁不是一开始就出现的而是某个时间点并发量上来了比如双十一秒杀场景某个线程执行慢了另一个线程在等待时新增了一个嵌套锁调用然后死锁概率从 0.001% 上升到 10%压测就暴露了。这就是为什么我在写代码时非常强调锁的顺序统一如果两个资源总是以同样的顺序获取循环等待条件就能被打破。比如所有需要多个锁的路径都按锁1 再锁2的顺序来那就不可能循环。6.2 怎么快速定位死锁现场定位死锁最常见的方式是抓 dump。在 Windows 上可以任务管理器右键进程创建转储文件在 Linux 上用 dotnet-dump 命令。拿到 dump 之后用 dotnet-sos 的 threads 命令和 clrstack 命令查看每个线程的托管调用栈。死锁现场最典型的特征是两个线程的栈分别停在 Monitor.Enter 或者 WaitHandle.WaitOne 上而且它们的指令指向的锁对象 ID 能对应上。另外你可以用超时 日志的手段提前发现死锁。比如把 lock 语句替换成 Monitor.TryEnter(obj, TimeSpan.FromSeconds(2))返回 false 说明 2 秒内没拿到锁记一条日志。这个改动对性能影响不大但能让你在死锁即将发生的时候看到警告。我见过某团队的定时任务系统就是这样加了超时日志后每次慢操作都能自动告警而不是等到客户投诉。6.3 事后处理超时、顺序与异常恢复死锁发生后靠人工重启服务只是治标。你要做的第一件事是修复代码里锁顺序不一致的问题。如果实在改不动可以用锁超时来兜底Monitor.TryEnter 超时后抛异常或者记日志至少让调用方有机会恢复。另一个办法是减少持锁时间把不必要的代码移出临界区。还有一点容易被忽略死锁往往伴随着线程池耗尽。当线程池线程被死锁全部占用后续的 Task 排队等待现象就是 CPU 不高但请求全部超时。这时候你要监控线程池的状态比如记录 ThreadPool.ThreadCount 的数量超过某个阈值就要告警。除了死锁还要小心活锁和饥饿。活锁是线程一直重试但没有进展比如拿不到锁就无限重试然后释放又重试。饥饿是某个低优先级线程一直等不到资源。这些看起来和死锁相似但现象不同处理方式也不同。我把这套排查思路整理成了一个小清单先确认线程栈是否都在等待锁再检查锁顺序是否统一然后看持锁时间是否过长最后验证是否线程池耗尽。大多数并发问题都能在这四步里找到答案。踩过这么多坑之后我最大的体会是多线程实现本身并不难难的是在复杂业务里做到既安全又高效。每次代码审查的时候我都会下意识问几个问题这个共享资源能不能用并发容器代替锁这个 lock 块是不是可以再小一点这个 await 后面有没有必要捕获上下文取消逻辑有没有渗透到所有循环里这些问题问多了写出来的代码自然就稳了。这篇文章先更新到这里后续我要是再撞上新的并发难题会继续补进来。