.NET ThreadPool大量调度CPU密集任务时是否有机制避免I/O性能下降

大量CPU-bound任务占满线程池的影响 #

• 当CPU算力已经达到上限时，额外新增线程只会带来更多上下文切换开销，反而降低整体吞吐量。如果所有线程池线程都被长时间运行的CPU任务占用，确实会出现IO绑定操作的延续任务排队延迟，也就是线程池饥饿。
• 注意IO操作本身不会占用线程池线程，只有当IO完成后的回调/延续任务需要被调度到线程池执行时，才会和CPU-bound任务竞争资源。

ThreadPool的内置保障机制 #

• 线程动态注入逻辑：线程池默认最小线程数等于当前机器的CPU核心数，在最小线程数范围内，新到任务会立即分配线程；超过最小线程数后，线程池会每500ms尝试注入一个新线程，直到达到最大线程数上限（默认值远大于常规业务需要），缓解队列积压。
• 队列调度逻辑：线程池采用全局队列+线程本地队列的双层队列设计。IO完成后的回调默认进入全局队列，空闲线程优先从全局队列取任务执行；Task.Run提交的普通CPU任务默认进入当前线程的本地队列，一定程度上避免IO回调被大量本地队列的CPU任务堵住。
• 优先级支持：.NET 6+ 支持为线程池工作项设置优先级，你可以主动将CPU-bound任务设为低优先级，保障IO延续任务的调度优先级。
• 对于执行时间特别长的CPU任务，可以在调用Task.Run时指定TaskCreationOptions.LongRunning，这类任务会直接创建独立的非线程池线程执行，完全不占用线程池的线程资源。

ASP.NET Core场景的适配方案 #

ASP.NET Core本身默认没有同步上下文，所有await后的延续任务都直接调度到线程池执行，针对这类混合负载场景有几个层面的保障和最佳实践：

• Kestrel服务器默认提供了最大并发连接、最大并发请求的配置限制，避免请求量级过载直接打满线程池。
• 通用最佳实践是主动限制CPU-bound任务的并行度：使用SemaphoreSlim控制同时执行的媒体处理任务数量，比如将并行度设为Environment.ProcessorCount - 1，预留至少1个核心的算力给请求处理和IO延续任务，从根源上避免CPU资源被完全占满。
• 负载极高的场景下建议将重负载媒体处理逻辑拆分为独立的后台服务，和ASP.NET Core Web服务部署在不同进程甚至不同节点，彻底隔离两类负载的资源竞争。

内容的提问来源于stack exchange，提问作者nugetminer23