ThreadPool导致GUI冻结（？）

Question

我注意到，如果我的IO密集型应用程序的ThreadPool max线程数设置得太低（16），那么我的GUI将冻结。但是如果我把它设置得相当高（250），它就可以工作。

任何人都可以解释这种现象吗？

Answer 1

哇！除非知道自己在做什么，否则不要惹恼ThreadPool计数 - 许多重要的.NET服务可能正在使用它，并且依赖于它不饱和。你几乎可以肯定通过饱和将一些基本的IO代码解锁了。

我会想象它是被绊倒了，你在这个特殊的情况下，IO完成端口...

乔·达菲（谁比我会知道更多关于线程）对这个here的一些想法。

重新如何通过饱和使其死锁 - 这在思维实验中很容易重现;假设你有一些需要做2件事的工作者代码......我们将其中的1件推到ThreadPool上，并自己做一件事;在完成我们自己的工作后，我们将Join（）[或ThreadPool等价物]第二个任务，以便我们知道两者都已完成。

现在想象一下，我们在最后一个可用的ThreadPool线程上启动这个工作者代码：我们自己做了工作，然后等待第二个任务已完成的信号 - 但是没有可用的线程来完成它！因为我们还在等待，所以我们无法释放我们自己的。

您可以对IO完成端口执行相同的操作。