.NET Core线程池队列堆积：CPU未满载为何不创建新线程？

结合你提供的dotnet-counters监测数据，出现这种现象的核心原因可以从以下几个方面分析：

1. .NET线程池的渐进式线程注入机制 #

.NET线程池不会在任务队列堆积时立即创建大量新线程，而是采用渐进式注入策略来避免线程过多导致的上下文切换开销：

• 初始阶段会快速创建线程（通常匹配CPU核心数），但当队列任务持续增加，后续线程的创建会被限制速率（默认约每500毫秒创建1个新线程）。
• 如果任务进入队列的速度远快于线程注入的速度，就会出现队列堆积，哪怕CPU还没满载。你的场景中线程池线程数仅13，远低于系统支持的上限，但注入速率限制了新线程的生成速度。

2. 现有线程处于阻塞状态而非CPU繁忙 #

虽然CPU使用率显示81%，但这并不代表所有线程都在执行CPU密集型工作：

• 监测数据中Monitor Lock Contention Count达到79次/秒，说明存在频繁的锁竞争，大量线程可能处于等待锁释放的阻塞状态。
• 如果工作任务包含IO操作（如数据库、网络请求），线程会挂起等待IO完成，此时CPU资源空闲，但线程池不会因为CPU空闲就无限制创建线程——线程池的调度逻辑基于线程的忙碌状态（是否在执行任务），而非CPU使用率。

3. GC与JIT的额外开销占用资源 #

从数据来看，你的应用存在显著的GC和JIT开销，间接拖慢任务处理速度：

• Allocation Rate高达64MB/秒，% Time in GC为8%，频繁的GC会导致线程停顿，无法及时处理队列任务。
• Time spent in JIT达到1451ms/秒，大量的即时编译会占用线程资源，让线程暂时无法处理业务任务，进一步加剧队列堆积。

4. 线程池配置或任务特性限制 #

• 虽然系统理论支持20万线程，但.NET线程池默认有最大线程数限制（64位系统默认32767），不过你的场景中13个线程远未触及上限，所以更可能是注入速率限制。
• 如果任务本身是长耗时任务，线程池线程会被长时间占用，新任务只能排队等待，而线程池不会为长耗时任务快速创建线程（这是线程池的设计初衷——适合短任务）。

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