ThreadPool vs专用线程 - 何时更喜欢哪个

Question

当我应该停止使用ThreadPool并使用专用的Thread时，是否有任何方法（除了实际的性能测量非常难以实现）或经验法则？我认为对于长时间的工作，最好使用专用的Thread，因为它不会从ThreadPool中偷取一个。{1}}。对于较短的工作，最好使用ThreadPool，因为创建线程和线程本身会消耗大量资源。

但魔法屏障在哪里？我如何决定使用哪种方法？

在简单的应用程序中，它可能并不重要。但我正在处理一个基于.NET的自定义应用程序框架，其中单个应用程序可以拥有 lot 插件，在大多数情况下需要异常地完成一些工作。我正在考虑为插件作者引入一个策略何时使用哪个。

Answer 1

可量化。在我的双核笔记本电脑上，线程池调度程序每秒两次释放额外的tp线程，如果正在运行的那些线程没有进展。所以“长”超过半秒钟。

我不知道这是如何扩展更强大的硬件。它很容易测试，只需启动16个tp线程并让它们写入DateTime.Now和Sleep（8001）。

此外，任何在锁定或慢速I / O上长时间阻塞的线程都应该是常规线程。因为处理器不会执行任何有用的工作，所以阻塞线程阻止可能有用的工作的其他tp线程运行至少半秒。当然，这使得这样的线程几乎自动成为“长”线程。

Answer 2

将线程池线程用于短期运行任务。

如果您需要长时间运行的任务或需要设置线程的某些属性（如优先级，前景，文化等），请使用线程。

如果可能，请使用.NET 4中的Task类。默认调度程序使用线程池，但您可以提供自己的调度程序，从而精确控制任务映射到线程的方式。

Answer 3

如果你的应用程序要使用很多线程，你可以增加ThreadPool中的最小线程数，以避免出现瓶颈。我没有看到专用线程的任何优点。唯一想到的是你可以中止一个专用线程（无论如何这是不可取的）。

表现应该是一样的。 .NET 4.0框架中的任务并行库仅使用ThreadPool，因此它对您的项目也不应该是一个问题。

Answer 4

尚未提及的一点：设置线程静态类引用的代码通常不应从线程池线程运行。否则，如果线程被回收，则线程静态对象引用可能无限期地存在，从而直接或间接地阻止对象及其引用的所有其他对象符合垃圾回收的条件。