C# 为什么线程池以这种方式管理线程？

Joe Albahari在他的C#e-book中提供了.NET线程池的自动线程管理的一个例子，以及为什么它会这样工作

据我所知，默认情况下，在占用了处理器的所有内核之后，线程池会延迟新线程的创建，因为如果所有处理器内核都忙于进行计算，那么创建新线程将无法再提高应用程序的总体吞吐量（每秒完成的任务），新线程只是浪费系统资源

但是，如果任务在线程池队列中的时间过长，线程池将假定池中的线程以某种方式处于空闲或阻塞状态，并通过并发运行任务来尝试利用停机时间

在许多情况下，采用线程池线程具有表示“等待”状态的特殊属性的技术，而不是这种“延迟”算法，不是更有意义吗？它可能看起来像这样：

System.Threading.Thread.CurrentThread.IsWaiting = true;

线程池将立即为排队的任务创建新线程，直到所有处理器核心都被非等待线程占用。然后，任务被保留在队列中，直到线程完成或发出等待状态的信号

这将有几个好处。首先，如果处理器核心处于空闲状态，任务总是在排入池队列时立即启动，没有延迟。其次，在一个运行大量计算密集型任务的应用程序中，完成这些任务需要半秒以上的时间，线程池不会继续为系统增加不必要的额外线程

当然，在某些情况下，应用程序可能需要在严格的截止日期内完成任务，而不能等待其他任务先完成。此算法可能不适用于这些应用程序。否则，我认为这只会提高多线程应用程序的效率

---

您觉得怎么样？

我们在

Thread.ThreadState

属性中提供了这些信息。但是线程池使用这些信息不是一个好主意。要使用它，我们需要线程之间的通信（线程池中的线程和另一个收集信息的线程）。这将意味着需要一些同步，或者至少是易失性访问。两者都很贵。因此，我们会给ThreadPool的所有应用程序带来运行时负担，而只有少数应用程序会受益

作为一名程序员，您必须反映线程池的使用方式。如果标准行为不适合您，可以调整池。例如，如果您知道有许多等待线程，请使用

ThreadPool.SetMinThreads

。它不会像你希望的那样自动。但是您的自动化也不是完美的，因为当一些等待的线程同时唤醒时，我们可能会有太多的线程在运行

---

请注意，其他线程池根本没有非常聪明的扩展heuristitc，它内置于C#variant中。通常情况下，您有固定数量的运行线程，并且运行的线程数永远不会超过这个数量。

当然。但这一特征并不存在，所以这只是一种发呆。让线程池线程在I/O完成时浪费时间是一个错误。从程序中删除bug是程序员的工作，并发分析器是查找此类bug的首选工具。