ASP.NET Core应用ThreadPoolWorkQueue.Dispatch高CPU使用率排查求助

是否为已知问题 #

ThreadPoolWorkQueue.Dispatch是.NET线程池调度任务的核心方法，其高CPU使用率本身并非普遍的框架已知Bug，但在特定场景下确实存在关联性能问题：比如早期.NET Core版本（3.1及以前）的线程池调度器优化不足，面对大量短任务时调度开销过高；或者任务队列频繁出现锁竞争、上下文切换，都会导致该方法CPU占比飙升。

其他排查方向 #

• 监控线程池队列积压：通过性能计数器ThreadPool Queue Length，或代码中调用ThreadPool.GetAvailableThreads与ThreadPool.GetMaxThreads计算队列待处理任务数。如果短任务持续堆积，Dispatch会频繁执行调度逻辑，直接推高CPU。
• 检查异步任务拆分粒度：若业务代码中大量创建极短生命周期的异步任务（如微秒级完成的Task），线程池调度这些任务的开销会远大于任务本身的执行成本，导致Dispatch持续高负载。
• 排查同步上下文异常：若第三方库或自定义代码不当修改了ASP.NET Core的SynchronizationContext，会导致任务调度时产生额外的上下文同步开销，拉高Dispatch的CPU占比。
• 升级.NET版本：.NET 6及后续版本对线程池调度器做了大量优化，包括任务窃取算法、队列分区等，能有效降低调度逻辑的CPU开销。
• 深挖性能分析调用栈：在Visual Studio性能分析器中展开ThreadPoolWorkQueue.Dispatch的子调用栈，定位具体耗时逻辑——比如是队列锁竞争、任务状态检查，还是线程唤醒逻辑，这能精准定位瓶颈。
• 排查第三方依赖的后台任务：部分日志、缓存、消息队列等第三方组件会在后台频繁向线程池提交任务，这类隐蔽的任务堆积也会导致Dispatch持续高负载。
• 检查ThreadPool.SetMaxThreads配置：若MaxThreads设置过高，线程池会创建过多工作线程，Dispatch需要调度的线程数量增加，也会导致CPU使用率上升，建议保持默认值或根据CPU核心数合理调整。

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