c# - 在这种情况下，ThreadPool 值得吗？

Question

每次用户扫描条形码时，我都会触发一个线程。

大多数时候它是一个相当短的运行线程。但有时可能需要很长时间（等待对 GUI 线程的调用）。

我已经读过，为此使用 ThreadPool 可能是一个好主意，而不是仅仅为每次扫描创建我自己的线程。

但是我也读过，如果 ThreadPool 用完线程，那么它只会等到其他线程退出（对于我正在做的事情来说不行）。

那么，我将用完线程的可能性有多大？ThreadPool 的好处真的值得吗？（当我扫描时，扫描“运行”线程逻辑似乎不需要太长时间。）

Answer 1

这取决于您所说的“很长时间”是什么意思以及这种情况有多普遍。

MSDN 主题“托管线程池”为何时不使用线程池线程提供了很好的指导：

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

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

Answer 2

由于用户一次不会扫描多个条形码，线程池的内存成本可能不值得 - 我会坚持使用一个线程，只是在后台等待。

Answer 3

线程池的重点是摊销创建线程的成本，启动和拆除线程的成本并不低。如果您有一个短期运行的任务，则创建/销毁线程的成本可能占整个运行时间的很大一部分。线程池中的最大线程数取决于 .NET Framework 的版本，通常每个处理器几十到几百个。线程数根据可用工作进行缩放。

您会用完线程并不得不等待线程可用吗？这取决于你的工作量。您可以通过 ThreadPool.GetMaxThreads() 获得可用的最大线程数。有可能（根据您对问题的描述）这个数字足够高。

http://msdn.microsoft.com/en-us/library/system.threading.threadpool.getmaxthreads.aspx

另一种选择是管理您自己的扫描线程池并为它们分配工作，而不是为每次扫描创建一个新线程。就个人而言，我会先尝试线程池，并且仅在证明有必要时才管理自己的线程。更好的是，我会研究 .NET 中的异步编程技术。这些方法将在线程池上运行，但比手动线程管理为您提供更好的编程体验。

Answer 4

如果大部分时间是短时间运行的线程，您可以使用线程池或从池中提取线程的BackgroundWorker 。

Answer 5

在您的情况下，我可以看到的一个优势是线程池类对可能处于活动状态的线程数量设置了上限。是否会耗尽系统资源取决于应用程序的上下文。用尽现代桌面系统真的很难。

如果该软件在超市中使用，那么您几乎不可能同时分析超过 5 个条形码。如果它在后端服务器上运行一整排超市收银台。然后可能有 30-100 个并发请求可能处于活动状态。

通过这种理论设计，即使在嵌入式硬件上，您也不太可能用完线程。如果您一次有十几个处于活动状态的请求，并且您的代码有效，则可以保持原样。

线程池只是一个抽象，你可以在中间有一个队列，将请求排队到线程池中，在这种情况下，对于上面的 row-of-till 示例，我会觉得对 100-1000 个请求进行排队很舒服一个有 10 个线程的线程池。

Answer 6

在 .net 中（以及一般在 Windows 上），问题应该始终颠倒过来：“在这种情况下创建一个新线程值得吗？”

创建一个新线程很昂贵，而且一遍又一遍地做几乎肯定不值得。线程池很便宜，当你需要一个新线程时，它确实应该是你首先求助的东西。

如果你决定启动一个新线程，很快你就会开始担心如果它已经在运行，你会重新使用这个线程。然后你会开始担心有时线程正在运行但它似乎花费了太长时间，所以你应该创建一个新的。然后你将决定让一个线程在完成工作后不立即退出，而是等待一段时间以防新工作进入。然后...... bam！您已经创建了自己的线程池。此时您应该备份并使用系统提供的备份。

那些提到线程池可能“用尽线程”的人是善意的，但他们对你造成了伤害。线程池中线程数的限制是相当大的。如果你遇到它，你还有其他问题。

（当然，从 .net 2.0 开始，您可以设置最大线程数，因此您可以在绝对必要时调整该数量。）

其他人已将您定向到 MSDN：“托管线程池”。我会重复这个方向，因为文章很好，但在我看来，线程池卖得不够好。:)