.NET 5线程池GATE_THREAD_DELAY=500ms是否有误？实测线程注入间隔不符

首先明确结论：.NET 5的GATE_THREAD_DELAY默认配置确实为500ms，不存在配置错误，你观测到的1000ms间隔是线程池内置策略和测试误差共同导致的，核心原因如下：

1. 线程池爬山算法的注入节流逻辑 #

500ms只是线程池门控线程的固定唤醒间隔，不是每次唤醒都会实际注入新线程。
门控线程每次唤醒后会运行爬山算法评估当前工作负载：如果新增线程无法提升整体吞吐量（你的测试场景里所有工作项都卡在Task.Wait()，完全没有CPU运算，新增线程也不会带来任务处理速度的提升），算法会主动降低注入频率，甚至临时停止注入，这时候你观测到的间隔就会大于500ms。

2. 线程注入速率限制 #

.NET Core 3.0及之后的版本默认新增了线程注入速率限制：每秒最多注入2个新线程。这个策略是为了避免突发大量排队任务时线程暴涨导致的上下文切换开销，结合你的测试场景：
初始线程数默认等于CPU核心数（你的测试环境是8核，所以初始有8个可用线程），8个线程被占满后，剩下的8个排队任务按照每秒2个的速率注入，理论间隔是500ms，但叠加调度开销就会出现接近1000ms的观测结果。

3. 测试代码的统计误差 #

你统计的是Console.WriteLine的输出时间，不是线程实际创建完成的时间：

• Console本身是全局同步锁，多线程同时写控制台会出现排队等待，输出时间会晚于线程实际创建时间
• 线程创建完成后还要等待CPU调度才会执行代码逻辑，这段调度延迟也会被计入你观测的间隔中

验证方法 #

你可以在Main方法第一行添加如下代码，将线程池最小线程数调整为16：

ThreadPool.SetMinThreads(16, 16);

重新运行后你会发现所有16个任务几乎同时输出，没有明显的注入间隔，符合线程池在最小线程数范围内会立即创建线程满足负载的策略。

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