为什么线程池以这种方式管理线程？
Joe在伟大的解释的C#电子书中提供了一个.NET线程池的自动线程管理系统，以及它的工作方式。
根据我的理解，默认情况下，在占用了处理器的所有核心之后，线程池延迟了新线程的创建，因为如果所有处理器核都忙于计算，那么创建新线程就不能再提高应用程序的总吞吐量(每秒完成的任务)，而新线程只是浪费系统资源。
但是，如果任务在线程池队列中停留的时间太长，则线程池假设池线程以某种方式空闲或阻塞，并试图通过并发运行该任务来利用停机时间。
与这种“延迟”算法不同，在许多情况下，使用线程池线程具有一个特殊属性来表示“等待”状态的技术难道不是更有意义吗？它看起来可能是这样的：
System.Threading.Thread.CurrentThread.IsWaiting = true;线程池将立即为排队的任务创建新线程，直到所有处理器内核都被非等待线程占用为止。然后，任务在队列中保持，直到线程完成，或者发出等待状态的信号。
这会有几个好处。首先，如果处理器核心处于空闲状态，则任务总是在任务排队到池时立即启动，没有任何延迟。其次，在运行大量计算密集型任务(需要超过半秒钟才能完成)的应用程序中，线程池将不再为系统带来不必要的额外线程负担。
当然，在某些情况下，应用程序需要在严格的截止日期内完成任务，而不能等待其他任务先完成。该算法可能不适用于这些应用程序。否则，我认为它只会提高多线程应用程序的效率。
你认为如何？
回答 1
Stack Overflow用户
发布于 2014-12-03 12:30:52
我们在Thread.ThreadState属性中获得了此信息。但是，对于线程池来说，使用这些信息并不是个好主意。要使用它，我们需要线程之间的通信(线程池中的线程，以及另一个收集信息的线程)。这意味着一些同步需求，或者至少是易失性访问。两者都很贵。因此，我们将给ThreadPool的所有应用程序增加运行时负担，而只有少数几个应用程序会从中受益。
作为一个程序员，您必须反映线程池是如何使用的。如果标准行为不适合您，则可以调整池。使用ThreadPool.SetMinThreads，如果您知道您有很多等待线程。它不会像你想的那样自动。但是，您的自动化也不是完美的，因为当一些等待的线程同时醒来时，我们可能有太多的线程在运行。
注意，其他线程池根本没有构建在C#变体中的非常聪明的扩展启发式。通常情况下，运行线程的数量是固定的，并且运行的线程数永远不会超过这个数目。
https://stackoverflow.com/questions/27264774
复制相似问题
腾讯云开发者
