ThreadPool SetMinThreads - 设置它的影响

Question

我想了解设置ThreadPool.SetMinthreads的影响。我在一个Azure应用服务中运行了多个虚拟应用程序。我的理解是，所有这些虚拟应用程序将共享App Pool，并且只有一个工作进程（假设App Pool的最大工作进程为1）。

我有以下两个问题。

1. 在此设置中，如果我设置ThreadPool.SetMinThreads让我们说100个工作线程和IO线程，我可以安全地假设每个应用程序域在加载时将有100个工作线程和100个IO线程吗？确切地说，ThreadPool.SetMinThreads适用于AppDomain或工作进程或应用程序池？ ThreadPool的范围是什么？
2. 我还假设系统可以产生的最大线程没有限制，因为它是由底层主机的容量决定的。这意味着，如果我没有显式设置ThreadPool.SetMaxThreads，系统将产生新线程，并且如果持续加载直到CPU /内存达到最大值，它将继续执行。我基于以下陈述来支持我的假设：

  例如，进程和线程需要物理内存，虚拟内存   内存和池内存，所以进程或线程的数量   可以在给定的Windows系统上创建最终由   这些资源之一，取决于进程或方式   创建线程并首先命中哪个约束。   的 https://blogs.technet.microsoft.com/markrussinovich/2009/07/05/pushing-the-limits-of-windows-processes-and-threads/

Answer 1

MinThreads控制产生的工作线程数没有延迟。

每当您执行需要线程池中的线程（无论是工作线程还是IOCP池）的事情时，系统将首先查看是否存在空闲线程。

如果没有，它会查看当前产生的线程数。如果该数字小于MinThreads，它会立即生成一个新线程。否则它会等待很短的时间，通常在3到500毫秒左右，尽管这取决于系统。如果仍然没有自由线程，它将生成一个新线程。

当然，这一切仍然受到MaxThreads的限制。

所有这一切，IIS非常擅长根据您的机器计算合理的数字，在大多数情况下，您最好不要管它;如果您只是担心提供请求，那么我不会亲自触摸它。另一方面，如果你自己产生了很多背景任务，那么这可能是明智的。我强烈建议您在实际进行更改之前对其进行测量。

虽然......将MinThreads设置为100很少有害，特别是因为系统只会启动它实际需要的线程数