ThreadPool不会立即启动新线程我有一个启动各种对象（类库）的C#Windows服务。通过使用ThreadPool启动多个长时间运行的处理线程，这些对象中的每一个都有自己的“处理”逻辑。我有一个这样的例子：System.Threading.ThreadPool.QueueUserWorkItem(newSystem.Threading.WaitCallback(WorkerThread_Processing));这很好用。我的应用程序没有任何问题，我的线程运行良好。现在，为了进行回归测试，我启动了同一个对象，但是是从C#控制台应用程序而不是Windows服务。它调用完全相同的代码（因为它调用相同的对象），但WorkerThread_Processing方法在启动前最多延迟20秒。我进去并从ThreadPool切换到Thread，问题就消失了。这里会发生什么？我知道我没有超过MaxThreads计数（我最多启动20个线程）。ThreadPool对于长时间运行的项目特别有用（更具体地说，当您使用ThreadPool时，您甚至不必启动新线程，因为它的目的是在有限数量的线程中分配任务）。如果您的任务是长时间运行的，您应该将其分解成放在ThreadPool上的逻辑部分（或使用新的Task框架），或者启动您自己的Thread对象。至于您遇到延迟的原因，ThreadPool类的MSDN文档说明如下：作为其线程管理策略的一部分，线程池在创建线程之前会延迟。因此，当许多任务在短时间内排队时，在所有任务开始之前可能会有很长的延迟。您只知道ThreadPool没有达到其最大线程数，而不知道它实际空闲的线程数（如果有的话）。线程池的最大线程数是它可以创建的最大线程数。它不是已创建的最大数量。线程池具有阻止它同时激活一大堆线程的逻辑。如果快速连续调用ThreadPool.QueueUserWorkItem10次，线程池不会立即创建10个线程。它将启动一个线程，延迟它，启动另一个，等等。我似乎记得延迟是500毫秒，但我找不到文档来验证这一点。它是：托管线程池：线程池在启动新的空闲线程之前有一个内置延迟（在.NETFramework2.0版中为半秒）。如果您的应用程序在短时间内定期启动许多任务，则空闲线程数量的小幅增加可以显着提高吞吐量。将空闲线程数设置得太高会不必要地消耗系统资源。您可以使用GetMinThreads和SetMinThreads来控制线程池维护的空闲线程数请注意，此引用来自.NET3.5版本的文档。.NET4.0版本没有提到延迟。以上就是C#学习教程：ThreadPool没有立即开启新线程共享所有内容。如果对大家有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权请点击右侧联系管理员删除。如需转载请注明出处：
