工作线程执行CPU密集型任务，如数学计算、字符串处理等；IO线程仅处理I/O完成通知，不执行实际读写。两者共享线程池调度器但生命周期独立，不可混用。
工作线程（workerThreads）是干什么的？
工作线程执行的是「CPU密集型」任务，比如数学计算、字符串处理、对象序列化、内存排序等——这些操作全程需要 CPU 持续参与，不能偷懒。你调用 ThreadPool.QueueUserWorkItem 或 Task.Run（默认不带 TaskCreationOptions.LongRunning）时，底层几乎总是从工作线程池里取线程。
- 默认初始数量为 0，首次请求时才创建；可通过
ThreadPool.SetMinThreads(2, 0)预热 2 个空闲工作线程 - 最大数量默认通常是 CPU 核心数 × 500（.NET 6+ 可能更高），但 Windows 下一般不超过 32767
- 它不是“专干计算”的线程，而是“不涉及系统级异步 I/O 完成通知”的通用后台线程
- 如果你在工作线程里阻塞式读文件（
File.ReadAllBytes）、发同步 HTTP 请求（HttpClient.Send），就等于把工作线程当 IO 线程滥用——会拖慢整个池的响应速度
IO线程（completionPortThreads）到底是不是在做IO？
不是。IO 线程不执行真正的读写，只负责「处理 I/O 完成通知」——也就是当 Windows 的 I/O 完成端口（IOCP）触发回调时，由它来跑那个回调逻辑。换句话说：BeginRead/EndRead、FileStream.ReadAsync、Socket.AcceptAsync 这类真正异步的 I/O 操作，其完成后的回调函数，大概率在线程池的 IO 线程上执行。
- IO 线程由 CLR 内部调度，开发者通常不直接调用；你无法用
QueueUserWorkItem把任务“指定”到 IO 线程 - 它的最小/最大值可独立设置：
ThreadPool.SetMinThreads(0, 2)表示至少预留 2 个 IO 线程（对高并发 Socket 服务很有用） - 注意：.NET Core 3.0+ 和 .NET 5+ 中，
ThreadPool.GetAvailableThreads返回的第二个参数仍是completionPortThreads，但底层已统一为基于 epoll/kqueue/IOCP 的跨平台异步模型，语义未变 - 常见误判：看到
await File.ReadAllTextAsync(...)回调很快，就以为“IO线程在干活”——其实磁盘读本身由系统驱动完成，线程只是收了个通知
为什么不能只靠工作线程扛所有异步？
因为工作线程一旦被阻塞（比如等一个没超时的 HttpClient.GetAsync），它就卡住了，不能再接新任务；而 IO 线程池的设计初衷，就是让「等待硬件完成」这件事不占用任何活跃线程资源。
- 举例：1000 个并发 HTTP 请求，若全用工作线程 + 同步等待，可能瞬间耗尽 1000 个工作线程，后续任务排队甚至饿死
- 正确做法是用
async/await+ 基于 IOCP 的原生异步 API（如HttpClient.GetStringAsync），让线程在等待期间释放回池中 - 调用
ThreadPool.GetMaxThreads(out int wt, out int cpt)查看当前配置，你会发现cpt（IO 线程上限）常比wt（工作线程上限）小得多——这是有意为之：IO 完成通知本身极轻量，不需要太多线程来承载 - 陷阱：在 ASP.NET Core 中手动调用
ThreadPool.SetMinThreads(100, 100)并不能提升吞吐，反而可能因线程争抢导致 GC 压力增大；现代框架已自动适配负载
怎么查当前用了多少工作线程和IO线程？
用 ThreadPool.GetAvailableThreads 是最直接的方式，但它返回的是「可用数」，不是「已用数」，需自己推算：
int workerAvail, ioAvail;
ThreadPool.GetAvailableThreads(out workerAvail, out ioAvail);
int workerMax, ioMax;
ThreadPool.GetMaxThreads(out workerMax, out ioMax);
Console.WriteLine($"工作线程：{workerMax - workerAvail}/{workerMax}，IO线程：{ioMax - ioAvail}/{ioMax}");- 这个值只反映线程池“当前愿意拿出来干活”的线程数，不代表操作系统实际创建了多少内核线程
- 在高负载下，
workerAvail可能长期为 0，但线程池会自动扩容（只要没到SetMaxThreads上限） - 不要在生产环境频繁轮询这个值——它本身有轻微开销，且结果滞后；更适合用于诊断性日志或压测后分析
- 真正关键的指标其实是
ThreadPool.GetPendingWorkItemCount()：它告诉你还有多少任务在排队，比“用了几个线程”更能说明瓶颈在哪
真正容易被忽略的一点是：工作线程和 IO 线程共享同一个线程池调度器，但它们的生命周期、触发条件、扩容策略完全独立。你在代码里写 await Task.Delay(1000)，既不走工作线程也不走 IO 线程——它靠的是 .NET 的内部定时器队列，和这两个池都没关系。
