线程池饥饿的典型表现和根本原因
当你看到
ThreadPool.GetAvailableThreads返回值长期为 0，而
ThreadPool.GetMaxThreads和
ThreadPool.GetMinThreads却没被调高，同时大量
Task在队列里堆积（
ThreadPool.GetPendingWorkItemCount()持续 >100），基本可以断定发生了线程池饥饿——不是线程不够，而是它们全卡在同步阻塞点上，无法释放回池中。
最常见诱因是「伪异步」：比如在
Task.Run里调用
.Result或
.Wait()，或使用新版
MySql.Data的
Open()、
ExecuteReader()等同步方法——它们底层其实是
GetAwaiter().GetResult()，会强行阻塞线程池线程等待 I/O 完成，把本该让给其他任务的线程“钉死”在那儿。 不要在
async方法里写
SomeAsyncMethod().Result；改用
await SomeAsyncMethod()避免
Task.Run(() => dbConnection.Open())；直接用
await dbConnection.OpenAsync()检查所有第三方 SDK 的同步 API 文档——尤其是数据库、HTTP、文件操作类库，确认它们是否是“同步外壳+异步内核”
ThreadPool 是怎么“注入新线程”的？
.NET 的线程池不会无限制创建新线程。它按需扩容，但有延迟和上限：默认最小线程数（
MinThreads）通常是 CPU 核心数，最大线程数（
MaxThreads）默认是 32767（.NET 6+）。当所有线程忙且队列积压时，线程池每 500ms 尝试增加一个线程，直到达到
MaxThreads或积压缓解。
这个机制对突发 I/O 请求不友好——因为新增线程要等半秒，而你的请求可能已在超时边缘。更糟的是，如果线程全被
.Result卡住，线程池根本“意识不到”这是阻塞型负载，只会傻等，不会主动扩容。 可通过
ThreadPool.SetMinThreads(100, 100)提前垫高底线（仅限 I/O 密集型服务，慎用） 永远不要依赖自动扩容来掩盖阻塞代码；扩容只是兜底，不是解药
ThreadPool.GetAvailableThreads的返回值包含“可用工作线程”和“可用完成端口线程”，后者专用于异步 I/O 回调——饥饿通常只影响前者
别用 Task.Run 包裹异步方法
这是新手高频雷区：
Task.Run(() => GetDataAsync().Result)表面看是“扔进后台”，实则把一个本可非阻塞的异步调用，硬塞进线程池线程并让它同步等结果——等于用宝贵的工作线程干了 I/O 等待的活，还白占一个线程。
public async Task<string> GetUserInfoAsync(int id)
{
// ✅ 正确：全程异步流转，不占用线程池线程等待
using var client = new HttpClient();
return await client.GetStringAsync($"https://api.example.com/users/{id}");
}
public string GetUserInfoSync(int id)
{
// ❌ 危险：Task.Run + .Result = 双重浪费
return Task.Run(() => GetUserInfoAsync(id).Result).Result;
}
I/O 操作一律走 async/await，别绕路
Task.RunCPU 密集型任务才考虑
Task.Run，且确保内部无任何
await或阻塞调用 若必须兼容同步接口，用
GetAwaiter().GetResult()比
.Result略好（避免二次异常包装），但仍属下策
真正可控的“新线程”只有 Thread.Start
线程池之外，唯一能立即、确定性创建新线程的方式就是
new Thread(() => { ... }).Start()。但它代价极高：每次创建销毁开销大、不复用、易失控，且无法被 async/await捕获上下文（
SynchronizationContext丢失）。
所以除非你在做极特殊的场景（如长时间运行的独立监控线程、需要固定优先级的实时任务），否则绝不该用它替代线程池或异步模型。
Thread不受线程池调度控制，
ThreadPool.SetMaxThreads对它无效 手动管理
Thread时，务必配合
CancellationToken实现协作式退出，禁用
Thread.Abort()ASP.NET Core 等托管环境会主动回收前台线程，用
Thread.IsBackground = true防止进程挂起
线程饥饿从来不是线程数量问题，而是线程使用方式的问题。把阻塞点从线程池里清出去，比拼命调大
MaxThreads有用一百倍——尤其当你发现
ExecuteScalarAsync被卡在
GetResult()里时，那不是线程不够，是代码在“谋杀”线程。
