@xeaglex 测试了一下调大了最小线程数，新开的线程立马就飚了起来。

刚刚，细细思考一下 ThreadPool 这种延迟开新线程的行为存在的意义，发现一个事实：纯粹是微软某个程序员意淫出来的结果。

[1]

一般常见的池类配置存在两个控制参数：MaxActive 最大活跃数、MaxIdle 最大空闲数；你需要连接立即给你，只要不超过最大连接数，并且池内保留已开启的。

.net ThreadPool：只有 MaxThread 最大活跃数；你需要线程？看你设置了 MinThreads 没有，已开线程数量超过 MinThreads ？不好意思，新血液小水管慢慢流，等着业务超时吧。


[2]

ThreadPool 这个延迟功能初衷本来是好的，可以防止程序因为突然不好的原因（ bug 或者其他非预期因素）打开大量线程产生的问题 [非业务需求] 。但如果程序确实需要大量线程来处理，不管你怎么延迟，最终还是会开到满足需要的线程数量 [业务实际需求] ；此时 ThreadPool.SetMinThreads 入场。

但是因为程序功能需要，往往需要调用 ThreadPool.SetMinThreads 调大可快速开启的线程数量，由于 ThreadPool.SetMinThreads 算是一个竞争资源（下面 [3] 解释）。最终的设定会趋向于 ThreadPool.SetMinThreads==ThreadPool.SetMaxThreads，并且趋向于全局只初始化设定一次（如程序启动时）。

最终结果就是 ThreadPool.SetMinThreads 失去存在的意义，ThreadPool 延迟开新线程没有任何价值。


[3]

ThreadPool.SetMinThreads 存在竞争因素，不敢随意调用，最终结果趋向于在程序初始化时设定 ThreadPool.SetMinThreads==ThreadPool.SetMaxThreads。

注意：MinThreads 数量并非会保留的空闲（ Idle ）线程数量，是要新开线程时如果已开启线程数量没有超过 MinThreads 就会立即开启，否则等着吧。新开的线程超过时间没用会自动关闭，具体保留多少个空闲（ Idle ）线程，没有设置方法。

默认：SetMinThreads 10
事物 A：事物开始时 SetMinThreads 200 （实际需要 100-300 个线程），事物结束还原成 10
事物 B：事物开始时 SetMinThreads 50 （实际需要 50-80 个线程），事物结束还原成 10

竞争情况：AB 都在运行（无需管谁先开始的），A 需要 30 分钟，B 需要 5 分钟，不管谁先结束，MinThreads 都会变成比另外事物开始时设定值小，都 [有可能] 对另外一个事物产生影响。

解决办法：那就不在事物开始时设定，改成每次从线程池中拿线程时设定 MinThreads，问题解决！

然后演变变成了：

MinThreads=谁大谁说了算；

整个程序 MinThreads≈会最大设定那个值。

整个程序 MinThreads≈MaxThreads。


[结论]

当有相对多点的线程需求时，ThreadPool 这种延迟开新线程的行为没有意义。ThreadPool.SetMinThreads 废物，不如换成 SetMaxIdleThreads。

new Thread(run).Start()没这种问题，但线程启动耗时太长（到无法接受的程度）。ThreadPool.QueueUserWorkItem(run)和 Task.Run(run)共享 ThreadPool。

实现线程池比实现 HttpClient 简单 99 倍，是时候自己实现一个.net 的线程池了（大哭

-----

洋洋洒洒又写作文，测试+码字耗时 1 小时，学习就是这样的 @karllynn #70