C# 如何提升ThreadPool.QueueUserWorkItem的执行速度？

你遇到的是.NET 线程池默认的线程注入策略限制：默认情况下，当线程池的忙碌线程数达到设置的最小工作线程数后，每新增一个线程会有固定500ms的等待间隔，也就是你观察到的0.5秒延迟，该设计的初衷是避免短时间突发请求导致线程过度创建带来的额外开销。

核心调整方法 #

• 直接调高线程池最小工作线程、IO线程阈值：在服务启动的入口位置调用ThreadPool.SetMinThreads方法，建议将最小线程数设置为不低于你预期的峰值并发请求数，针对你的400并发场景，可以先设置为400，后续再根据压测结果调整到最优值

// 第一个参数为工作线程最小数，第二个为异步IO线程最小数
bool setSuccess = ThreadPool.SetMinThreads(400, 400);
// 可通过setSuccess返回值判断配置是否生效

• .NET Core/.NET 5+ 版本也可以通过配置文件调整，无需修改代码：在项目的runtimeconfig.json文件中添加如下配置即可

{
  "runtimeOptions": {
    "configProperties": {
      "System.Threading.ThreadPool.MinThreads": 400
    }
  }
}

• 注意不要盲目设置过高的最小线程数：每个线程默认会占用1MB的栈内存，过高的配置会带来不必要的内存开销，建议结合服务器硬件配置和实际压测结果调整。

高吞吐量场景额外优化建议 #

• 尽量避免在线程池线程中使用同步阻塞IO：同步阻塞会导致线程被长时间占用无法释放，变相拉高所需的线程总量，建议把业务逻辑中的同步IO改为异步await实现，配合异步服务端监听逻辑（比如ASP.NET Core原生异步处理管道、Socket的异步接收方法），可以大幅降低线程需求，从根本上提升吞吐量。
• 非必要不要调整线程池最大线程数：默认最大线程数通常足够使用（默认值为CPU核心数*32767），如果确实有调整需求，注意最大线程数不能低于你设置的最小线程数。
• 如果你的业务逻辑以CPU密集型计算为主：不要把最小线程数设置超过CPU核心数太多，过多的线程会导致频繁的上下文切换，反而会降低整体吞吐量。

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