40

什么时候不应该在 .Net 中使用 ThreadPool？

看起来最好的选择是使用线程池，在这种情况下，为什么它不是唯一的选择？

您对此有何经验？

4

9 回答 9

30

@Eric，我将不得不同意 Dean 的观点。线程很昂贵。您不能假设您的程序是唯一运行的程序。当每个人都贪图资源时，问题就会成倍增加。

我更喜欢手动创建线程并自己控制它们。它使代码非常容易理解。

合适的时候就好了。但是，如果您需要一堆工作线程，那么您所做的就是让您的代码更加复杂。现在您必须编写代码来管理它们。如果您只是使用线程池，您将免费获得所有线程管理。并且该语言提供的线程池很可能比您自己滚动的任何东西都更健壮、更高效且错误更少。

Thread t = new Thread(new ThreadStart(DoSomething));  
t.Start();  
t.Join();

我希望您通常在Start()和之间有一些额外的代码Join()。否则，多余的线程是没有用的，你在无缘无故地浪费资源。

人们太害怕线程使用的资源。我从未见过创建和启动线程花费超过一毫秒。您可以创建的线程数没有硬性限制。RAM 使用率极低。一旦你有几百个线程，CPU 就会因为上下文切换而成为一个问题，所以此时你可能想要对你的设计有所了解。

在现代硬件上，一毫秒是很长的时间。这是 3GHz 机器上的 300 万个周期。再说一次，你不是唯一一个创建线程的人。您的线程与所有其他程序的线程一起竞争 CPU。如果您使用了不太多的线程，另一个程序也是如此，那么您一起使用了太多的线程。

说真的，不要让生活变得比它需要的更复杂。除非您需要它提供的非常具体的东西，否则不要使用线程池。

确实。不要让生活变得更复杂。如果您的程序需要多个工作线程，请不要重新发明轮子。使用线程池。这就是它在那里的原因。你会推出自己的弦乐课程吗？

于 2008-08-13T21:05:26.250 回答
17

我不使用便宜的多线程的唯一原因ThreadPool是如果我需要……

  1. 与正在运行的方法交互（例如，杀死它）
  2. 在STA 线程上运行代码（这发生在我身上）
  3. 在我的应用程序死亡后保持线程处于活动状态（ThreadPool线程是后台线程）
  4. 以防我需要更改线程的优先级。我们无法更改默认为 Normal 的 ThreadPool 中线程的优先级。

PS： MSDN 文章“托管线程池”包含标题为“何时不使用线程池线程”的部分，其中包含一个非常相似但稍微更完整的不使用线程池的可能原因列表。

您需要跳过 的原因有很多ThreadPool，但如果您不知道它们，那么ThreadPool应该对您来说已经足够了。

或者，查看新的Parallel Extensions Framework，其中有一些简洁的东西可以满足您的需求，而无需使用ThreadPool.

于 2008-08-13T19:32:25.253 回答
9

只要您有工作线程的概念，线程池就有意义。任何时候您可以轻松地将处理划分为较小的作业，每个作业都可以独立处理，工作线程（因此是线程池）是有意义的。

当您需要执行完全不同且不相关的操作的线程时，线程池没有意义，这些操作不能被视为“作业”；例如，一个线程用于 GUI 事件处理，另一个用于后端处理。当处理形成管道时，线程池也没有意义。

基本上，如果您有启动、处理作业和退出的线程，那么线程池可能是要走的路。否则，线程池并没有真正的帮助。

于 2008-08-13T19:32:16.267 回答
9

对于 quarrelsome 的回答，我要补充一点，如果您需要保证您的线程将立即开始工作，最好不要使用 ThreadPool 线程。每个应用程序域的最大运行线程池线程数是有限的，因此如果它们都忙，您的工作可能不得不等待。毕竟，它被称为“队列用户工作项”。

当然，有两个警告：

  1. 您可以在运行时更改代码中线程池线程的最大数量，因此没有什么可以阻止您检查当前与最大数量并在需要时提高最大值。
  2. 启动一个新线程会带来时间上的损失——你是否值得接受这个打击取决于你的情况。
于 2008-08-13T19:34:29.273 回答
2

我不是作为一个只有理论知识的人说话。我编写和维护大量使用多线程的大量应用程序，我通常不认为线程池是正确的答案。

啊，来自权威的论点——但请始终留意可能在 Windows 内核团队中的人。

我们都没有争论这样一个事实，即如果您有一些特定的要求，那么 .NET 线程池可能不是正确的选择。我们反对的是创建线程的机器成本微不足道。

首先在 ThreadPool 的存在理由中创建线程的巨大费用。我不希望我的机器被那些被错误告知创建线程的费用的人编写的代码填充，并且不知道它会导致在每个单独的 DLL 中调用一个方法附加到进程（其中一些将由第 3 方创建），并且很可能会启动大量根本不需要在 RAM 中并且几乎可以肯定不需要在 L1 中的代码。

现代机器中内存层次结构的形状意味着“分散” CPU 的注意力是您可能做的最糟糕的事情，每个关心自己工艺的人都应该努力避免它。

于 2008-08-13T22:08:27.857 回答
1

当您要执行一个需要很长时间的操作时，或者可能是一个连续的后台线程。我想您总是可以将池中可用的线程数量推高，但不会产生永远不会返回池的线程的管理成本。

于 2008-08-13T19:27:42.673 回答
0

MSDN 在这里列出了一些原因：

http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

有几种情况适合创建和管理自己的线程而不是使用线程池线程：

  • 您需要一个前台线程。
  • 您需要一个线程具有特定的优先级。
  • 您的任务会导致线程长时间阻塞。线程池具有最大线程数，因此大量阻塞的线程池线程可能会阻止任务启动。
  • 您需要将线程放入单线程单元中。所有 ThreadPool 线程都在多线程单元中。
  • 您需要有一个与线程相关联的稳定身份，或者将线程专用于某项任务。
于 2012-08-13T04:45:32.770 回答
0

线程池线程适用于满足以下两个条件的任务：

  1. 该任务将不必花费任何大量时间等待某事发生
  2. 等待任务完成的任何事情都可能会等待许多任务完成，因此它的调度优先级不会对事情产生太大影响。

使用线程池线程而不是创建新线程将节省大量但有限的时间。如果该时间与执行任务所需的时间相比很重要，那么线程池任务可能是合适的。然而，执行任务所需的时间越长，使用线程池的好处就越小，任务阻碍线程池效率的可能性就越大。

于 2013-04-30T20:57:44.627 回答
-1

@埃里克

@Derek，我不完全同意您用作示例的场景。如果您不确切知道您的机器上正在运行什么，以及您的应用在一定负载下将使用多少总线程、句柄、CPU 时间、RAM 等，那么您就有麻烦了。

您是您编写的程序的唯一目标客户吗？如果不是，您无法确定其中的大部分内容。当您编写程序时，您通常不知道它是否会有效地单独执行，或者它是否会在受到 DDOS 攻击的网络服务器上运行。您无法知道您将拥有多少 CPU 时间。

假设您的程序的行为会根据输入而发生变化，甚至很难确切地知道您的程序将消耗多少内存或 CPU 时间。当然，您应该对程序的运行方式有一个很好的了解，但是大多数程序从不分析以确定将使用多少内存、多少句柄等，因为全面分析的成本很高。如果您不编写实时软件，那么付出的努力是不值得的。

一般来说，声称确切地知道你的程序将如何运行是牵强附会的，并且声称知道关于机器的一切都是荒谬的。

老实说，如果您不确切知道应该使用什么方法：手动线程、线程池、委托，以及如何实现它来满足您的应用程序的需求，那么您就有麻烦了。

我并不完全不同意，但我真的不明白这有什么关系。这个网站专门在这里，因为程序员并不总是有所有的答案。

如果您的应用程序足够复杂，需要限制您使用的线程数量，您是否几乎总是想要比框架提供的更多控制？

不。如果我需要一个线程池，我将使用提供的线程池，除非并且直到我发现它还不够。我不会简单地假设提供的线程池不足以满足我的需求，而无需确认是这种情况。

我不是作为一个只有理论知识的人说话。我编写和维护大量使用多线程的大量应用程序，我通常不认为线程池是正确的答案。

我的大部分专业经验都与多线程和多处理程序有关。我也经常需要推出自己的解决方案。这并不意味着线程池在许多情况下没有用或不合适。线程池是为处理工作线程而构建的。在适合多个工作线程的情况下，提供的线程池通常应该是第一种方法。

于 2008-08-13T22:05:27.050 回答