在C#服务端程序里，线程池是执行异步回调和Task的基础资源。当大量操作占用了池内所有工作线程，而新来的任务只能排队、无法及时得到执行时，系统就出现了线程池饥饿。理解它的成因并掌握规避手段，对编写高吞吐服务非常关键。
一、C#中线程池饥饿的定义与底层原理
线程池饥饿（Thread Pool Starvation）是指线程池中的工作线程全部被占用，且由于任务排队过长或线程注入不及时，导致后续任务长时间无法被执行的状态。C#的ThreadPool由CLR管理，默认包含工作线程和IO完成端口线程。工作线程用于执行Task、QueueUserWorkItem以及异步方法续接部分。
CLR对线程池线程的注入采取保守策略：当队列中有等待任务且现有线程都在忙时，大约每500毫秒才会新增一个工作线程，直到达到CPU核心数附近的阈值；之后注入更慢。如果短时间涌入大量阻塞调用（如同步HTTP请求、锁等待、Thread.Sleep），现有线程被耗尽，而新线程来不及补充，后续Task即使已调度也只能滞留在全局队列中。
1.1 饥饿与死锁的区别
很多开发者容易把饥饿和死锁混淆。死锁是多个线程互相持有对方需要的锁而永久等待，涉及依赖环路；线程池饥饿并没有环路依赖，只是资源（线程）不足导致吞吐下降或延迟飙升。从现象看，死锁会让CPU占用降为零，而饥饿时CPU可能仍较高，但请求响应时间持续变长。
可以用下面简单代码观察饥饿：在控制台程序里把线程池最大工作线程设小，然后提交大量阻塞任务，主线程打印的完成时间会急剧拉长。
using System;
using System.Threading;
using System.Threading.Tasks;
class Program
{
static void Main()
{
// 限制线程池最多4个工作线程
ThreadPool.SetMaxThreads(4, 4);
var tasks = new Task[20];
for (int i = 0; i < 20; i++)
{
tasks[i] = Task.Run(() =>
{
// 同步阻塞30毫秒，模拟耗时IO
Thread.Sleep(30);
});
}
Task.WaitAll(tasks);
Console.WriteLine("全部完成");
}
}
二、造成C#线程池饥饿的常见场景
第一类场景是同步阻塞调用混入异步流程。比如在ASP.NET Core里某接口内部调用了Result或Wait()来等异步方法，当前线程被卡住，同时池内其他线程也可能因类似写法被占满。第二类是CPU密集型任务直接丢进默认Task，没有标记LongRunning，导致和IO回调争抢同一批线程。
第三类是突发流量下大量短阻塞。例如每分钟定时从数十个第三方接口同步拉取数据，若使用Parallel.For加HttpWebRequest同步调用，瞬间占满线程池。以下表格列出典型误用与影响：
| 场景 | 代码示例特征 | 后果 |
|---|---|---|
| 异步方法内同步等待 | var data = GetAsync().Result; | 请求线程被占，吞吐骤降 |
| Parallel跑阻塞IO | Parallel.For(0,100, i=>{ WebRequest.Create(url).GetResponse(); }); | 线程池快速耗尽 |
| 大量Timer回调阻塞 | timer.Elapsed += (s,e)=>{ Thread.Sleep(100); }; | 回调排队，计时漂移 |
2.1 异步反模式示例
下面这段代码在Web接口中常见，却是饥饿诱因。它把本来可以释放线程的异步GET强行同步化：
// 错误示范：在接口中同步阻塞等待异步结果
public string GetData()
{
// 占用线程池线程直到网络返回
return httpClient.GetStringAsync("https://ipipp.com/api").Result;
}
如果并发请求数超过空闲线程数，新请求会在线程池队列等待，而老请求又在等网络，整体像被冻住。正确做法是用async/await让线程在等待时回去处理别的请求。
三、C#避免线程池饥饿的实用方案
核心思路是区分IO密集与CPU密集，并减少线程被无意义占用的时间。对于IO操作，始终使用真正的异步API（如HttpClient.GetAsync、Stream.ReadAsync），配合await，使等待期间线程回归池中被复用。对于CPU密集计算，使用Task.Factory.StartNew并指定TaskCreationOptions.LongRunning，让CLR单独开线程，不挤占池内常规线程。
另外，对必须同步执行的遗留代码，可放到专用线程或独立ThreadPool之外执行。例如自建一个固定大小的自定义线程池（或用Channel加消费线程）来处理阻塞任务，把默认线程池留给异步续接。以下为LongRunning用法：
// 将CPU密集型工作标记为LongRunning，避免拖垮线程池
var heavyTask = Task.Factory.StartNew(() =>
{
// 模拟计算
double sum = 0;
for (int i = 0; i < 10000000; i++) sum += Math.Sqrt(i);
return sum;
}, TaskCreationOptions.LongRunning);
// 异步IO保持await，不阻塞池线程
async Task<string> FetchAsync()
{
using var client = new HttpClient();
return await client.GetStringAsync("https://ipipp.com/api");
}
3.1 监控与参数调优
生产环境应监控线程池可用线程数及队列长度。通过ThreadPool.GetAvailableThreads定期采样，若可用数长期接近零，说明存在饥饿风险。必要时用ThreadPool.SetMinThreads提高最小线程数，让突发流量下更快开出线程，但最小值过大会增加上下文切换成本。
对于ASP.NET Core，还可限制同步执行路径，或在网关层做并发削峰。结合以上代码改造与配置，基本可以消除大部分C#线程池饥饿问题，保障系统在高负载时仍具备稳定响应能力。
四、总结排查思路
遇到接口延迟突增且CPU未跑满时，先怀疑线程池饥饿。用dotnet-counters观察threadpool-thread-count与queue-length，定位是否大量阻塞调用。随后将同步IO改异步、CPU任务隔离、调整最小线程数，即可系统性规避。
写好C#高并发程序的关键，在于尊重线程池的设计初衷：它是为短时回调与IO续接而生，不是用来扛长时间阻塞的容器。