ThreadPool 与专用线程 - 何时更喜欢哪个答案

【问题标题】：ThreadPool vs dedicated Thread - when to prefer whichThreadPool 与专用线程 - 何时更喜欢哪个
【发布时间】：2023-04-04 13:15:01
【问题描述】：

当我应该停止使用ThreadPool 并改用专用的Thread 时，有什么办法（除了实际的性能测量，这很难使它们变得真实）或经验法则？我想对于长期运行的工作，最好使用专用的Thread，因为它不会从ThreadPool 中窃取一个。对于较短的工作，最好使用ThreadPool，因为创建线程和线程本身会消耗大量资源。

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

在简单的应用程序中，它可能没那么重要。但我正在处理一个自定义的基于 .NET 的应用程序框架，其中单个应用程序可以有很多插件，在大多数情况下需要异步完成一些工作。我正在考虑为插件作者何时使用哪个政策。

【问题讨论】：

标签： .net multithreading architecture plugins threadpool

【解决方案1】：

这是可以量化的。在我的双核笔记本电脑上，如果正在运行的线程没有取得进展，线程池调度程序每秒会释放一个额外的 tp 线程。所以“长”是半秒多。

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

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

【讨论】：

【解决方案2】：

将线程池线程用于短时间运行的任务。

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

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

【讨论】：

但是魔法屏障在哪里？我如何决定使用哪种方法？ 什么是短什么是长？
@bitbonk：我不确定您能否确定适用于所有情况的特定指标，但您通常希望避免大循环、可能阻塞的操作等。
@bitbonk：另外，即使你能想出一个具体的数字，这也会与实现细节相关联，未来可能会发生变化。有些任务显然是短期运行的，而另一些任务显然是长期运行的。对于其余的，您可能需要尝试这两种方法以找到最佳解决方案。

【解决方案3】：

如果您的应用程序要使用大量线程，您可以增加 ThreadPool 中的最小线程数以避免出现瓶颈。我没有看到专用线程的任何优势。唯一想到的是您可以中止专用线程（无论如何都不建议这样做）。

性能应该相同。 .NET 4.0 框架中的任务并行库仅使用 ThreadPool，因此它对您的项目也不应该成为问题。

【讨论】：

您无法准确控制池线程何时执行。我也强烈建议不要增加线程池的大小；如果你需要这样做，很可能你需要重新考虑你正在使用的整个线程系统。您可以使用 Thread 类做其他事情，但不能使用池线程；比如获取/设置优先级、前景/背景……
另外，如果线程可能最终被阻塞以等待某种 IO 操作，您可能永远不应该使用 ThreadPool 线程。
有没有办法动态判断增加线程池线程数是否明智？假设我有 20 多个插件，每个插件都一直阻塞一个 ThreadPool 线程，我如何检测到它并向 ThreadPool 添加更多线程？毕竟这种方法是个好主意吗？
你无法控制线程何时开始是正确的，但它不会有任何“不必要的”等待。我也错过了诸如优先级之类的附加属性，因为我不必使用它们（大多数应用程序也不应该使用它们）。
@bitbonk，您不必增加（最小）线程数。它会自动增长，虽然算法远非完美，但你很难改进它。

【解决方案4】：

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

【讨论】：