为什么线程池会这样管理线程？ [关闭]答案

【问题标题】：Why does the Thread Pool manage threads this way? [closed]为什么线程池会这样管理线程？ [关闭]
【发布时间】：2014-12-03 06:03:58
【问题描述】：

Joe Albahari 在他的 Threading in C# 电子书中提供了 .NET 线程池的自动线程管理的 great explanation，以及它为何如此工作。

据我了解，默认情况下，线程池在占用了一个处理器的所有内核后，会延迟创建新线程，因为如果所有处理器内核都忙于计算，创建新线程就不能再提高整体吞吐量（应用程序每秒完成的任务），而新线程只是对系统资源的浪费。

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

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

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

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

这有几个好处。首先，如果处理器内核空闲，任务总是在它们排队到池中的那一刻开始，没有延迟。其次，在运行大量计算密集型任务（需要半秒以上才能完成）的应用程序中，线程池不会继续给系统带来不必要的额外线程负担。

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

你怎么看？

【问题讨论】：

当然。但该功能不存在，所以这只是肚脐凝视。让线程池线程在 I/O 完成上浪费时间是一个错误。从程序中删除错误是程序员的工作，并发分析器是查找此类错误的首选工具。

标签： c# .net multithreading algorithm threadpool

【解决方案1】：

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

作为程序员，您必须反映您的线程池是如何使用的。如果标准行为不适合您，您可以调整池。例如。使用ThreadPool.SetMinThreads，如果你知道你有很多等待线程。它不会像你希望的那样自动。但是您的自动化也不是完美的，因为当一些等待线程同时唤醒时，我们很容易运行过多的线程。

请注意，其他线程池根本没有非常聪明的扩展启发式，它内置于 C# 变体中。通常，您有固定数量的正在运行的线程，并且您运行的线程永远不会超过这个数量。

【讨论】：