【.NET】ThreadPool 与异步编程：线程池饥饿的排查和预防

前言

异步编程在 .NET 里已经普及多年，但「接口偶发变慢、CPU 不高、线程数却持续上涨」这类问题依然常见，十有八九和线程池饥饿有关。本文把线程池的工作方式、饥饿的成因、常见的阻塞代码模式和排查工具整理成一篇可操作的参考。

示例基于 .NET 8，不依赖任何具体项目框架。

一、线程池的工作模型

ThreadPool 维护两种队列：

• 全局队列：QueueUserWorkItem、Task.Run 等入口进入这里。
• 工作线程本地队列：任务内联创建的子任务优先进入本地队列，减少竞争。

工作线程空闲时会从「本地队列 → 全局队列 → 其他线程的本地队列」的顺序偷任务，这套偷取机制让嵌套并行有不错的吞吐。关键是线程数量：线程池按 hills-climbing 算法自适应增减线程，每秒最多注入约 1~2 个新线程，这就是饥饿时「等很久才恢复」的原因。

二、什么是线程池饥饿

线程池饥饿的本质：线程被阻塞任务占住，队列里还有活没人干。因为注入新线程很慢（秒级），阻塞的任务越多，排队延迟越大，表现就是接口周期性长尾。

典型源头是把异步方法用同步方式等待：

• .Result / .Wait() / .GetAwaiter().GetResult()
• Task.Run 里包异步再同步等待
• lock 块里 await（编译不过，但 lock(SemaphoreSlim.Wait()) 之类的变体很多）
• 自研同步 HTTP、同步数据库驱动混在异步链路里

三、一段可复现的饥饿示例

// 每个 .Result 都会占住一个线程池线程约 1 秒
app.MapGet("/bad", () =>
{{
    var a = GetDataAsync().Result;
    var b = GetMoreAsync().Result;
    return Results.Ok(a + b);
}});

// 修正版：一路 async 到底
app.MapGet("/good", async () =>
{{
    var a = await GetDataAsync();
    var b = await GetMoreAsync();
    return Results.Ok(a + b);
}});

压测 /bad 端点，几十并发后延迟会从毫秒级涨到秒级；同样压力下 /good 保持稳定。这是最便宜的压测验证方式。

四、为什么不能靠加大 minThreadCount 解决

调大 ThreadPool.SetMinThreads 能缓解症状（线程提前建好，不用慢慢注入），但治不了根：阻塞代码继续占线程，只是把恶化点往后推。正确的顺序是先消灭阻塞模式，容量参数只做保底。

五、排查工具

确认饥饿有三种常用手段：

1. EventCounters / Metrics：dotnet-counters monitor –process-id N 观察 threadpool-thread-count、queue-length、throughput，队列长度持续大于 0 就是典型信号。
2. dotnet-stack 抓栈：直接看线程都在等什么，如果大量线程卡在 WaitSynchronizationObject，基本实锤。
3. dump 分析：dotnet-dump collect 后用 dotnet-dump analyze 的 threadpool 命令，看队列深度和线程用途。

dotnet-counters monitor -p <pid> System.Runtime
dotnet-stack report -p <pid>
dotnet-dump collect -p <pid>

六、库作者的额外责任

写通用库时要额外注意：不要在库的同步 API 里偷偷 .Result；提供异步 API 时保证真异步（不假异步包装）；把「是否线程安全」写进文档。库的阻塞会在调用方放大成线程池问题，而且调用方很难定位到库。

七、生产使用注意事项

• 上线前对关键接口做并发压测，观察线程数曲线是否随并发线性上涨。
• minThreadCount 适度保底（例如 CPU 核心数到几十），不要设到几百。
• 把「禁止 .Result」写进 code review 检查项，或用 Roslyn 分析器在 CI 拦截。
• 第三方库接入前查一下是否真异步，老库用 Task.Run 隔离时控制并发上限。
• 长任务用 TaskCompletionSource 或专用后台服务承载，别占默认线程池。

总结

线程池饥饿的因果链很短：阻塞代码占线程 → 队列排队 → 注入新线程太慢 → 延迟飙升。修法也直接：全链路真异步，把同步等待从代码里清出去，容量参数只做保底。

推荐的落地顺序是：先用 dotnet-counters 确认症状，再抓栈找到具体阻塞点，修复后压测验证，最后把模式检查固化到 CI。异步问题大多不是玄学，是可以在开发期拦住的。