我试图了解设置ThreadPool.SetMinthreads的影响。我在一个 Azure 应用服务中运行多个虚拟应用程序。我的理解是，所有这些虚拟应用程序将共享应用程序池，并且只有一个工作进程(假设应用程序池的最大工作进程为1)。
我有以下两个问题。
- 在此设置中，如果我将 ThreadPool.SetMinThreads 设置为 100 个工作线程和 IO 线程，我可以安全地假设每个应用程序域将有 100 个工作线程和 100 个 IO 线程吗？已加载？准确地说，ThreadPool.SetMinThreads适用于AppDomain，还是Worker Process或App Pool？ ThreadPool的范围是什么？
- 我还假设系统可以生成的最大线程数没有限制，因为它由底层主机的容量决定。这意味着，如果我没有显式设置 ThreadPool.SetMaxThreads，系统将生成新线程，并且如果存在连续负载，系统将继续执行此操作，直到 CPU/内存达到最大值。我基于以下陈述来支持我的假设:
Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. https://blogs.technet.microsoft.com/markrussinovich/2009/07/05/pushing-the-limits-of-windows-processes-and-threads/
最佳答案
MinThreads 控制无延迟地生成多少个工作线程。
每当你做一些事情需要从线程池(无论是worker还是IOCP池)中获取线程时，系统都会首先查看是否有空闲线程。
如果没有，它会查看当前生成了多少个线程。如果该数字小于 MinThreads，它会立即生成一个新线程。否则，它会等待很短的时间，通常大约 300-500 毫秒，尽管这取决于系统。如果仍然没有空闲线程，它将生成一个新线程。
当然，这一切仍然受到 MaxThreads 的限制。
尽管如此，IIS 非常擅长根据您的计算机计算出一个合理的数字，在大多数情况下，您最好不要管它；如果您只是担心服务请求，那么我个人不会碰它。另一方面，如果您自己生成大量后台任务，那么这可能是明智的。我强烈建议您在实际进行更改之前对其进行衡量。
尽管...将 MinThreads 设置为 100 很少有害，特别是系统只会启动它实际需要的线程数
关于c# - ThreadPool SetMinThreads - 设置它的影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46834697/