线程池饥饿的根本原因是同步阻塞导致线程无法释放，典型表现为AvailableThreads长期为0、PendingWorkItemCount持续>100；最常见诱因是伪异步（如.Result/.Wait()、同步数据库API），应全程使用async/await避免阻塞。
线程池饥饿的典型表现和根本原因
当你看到 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 卡住，线程池根本“意识不到”这是阻塞型负载，只会傻等，不会主动扩容。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 可通过
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.Run - CPU 密集型任务才考虑
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() 里时，那不是线程不够，是代码在“谋杀”线程。
