Threadpool设计问题

Question

我有一个设计问题.我想要一些反馈来了解ThreadPool是否适合我正在编写的客户端程序.

我有一个客户端作为服务处理数据库记录运行.这些记录中的每一个都包含外部FTP站点的连接信息[基本上它是要传输的文件队列].他们中的很多人都是同一个主机,只是移动不同的文件.因此,我正在由主持人将它们组合在一起.我希望能够为每个主机创建一个新线程.我真的不在乎转移完成时,他们只需要完成所有工作(或尝试做)他们被分配,然后在完成后终止,清理他们在过程中使用的所有资源.

我预计不会建立超过10-25个连接.传输队列为空后,程序将等待,直到队列中再次出现记录.

ThreadPool是一个很好的候选者,还是应该采用不同的方法？

编辑:在大多数情况下,这是服务器上运行的唯一重要的自定义应用程序.

Answer 1

不,线程池不合适.线程池实际上是为"需要后台处理的短任务"而设计的,因为框架依赖于线程池线程的可用性,并且长时间运行的进程可能耗尽线程池.

Ftp传输需要相对较长的时间(即使有合理的超时),因此它们并不适合.您可以通过使用线程池获得,但如果您使用它,您可能还会发现自己遇到了无法解释的错误.这取决于您的应用程序使用依赖于线程池的框架功能(异步委托等)的程度.

MSDN主题" 托管线程池 "为何时不使用线程池线程提供了良好的指导:

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

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

Answer 2

从您的描述来看，线程池似乎很适合。

问题：

1. 线程池线程不会让您的进程在关闭时保持活动状态。确保这是您想要的行为。

2. 在较早的阅读中，当应用程序可能正在等待传入连接（如 Web 应用程序）时，将线程池与长时间运行的任务捆绑在一起可能会很糟糕。但是，听起来您正在运行一个专用的 Windows 服务，所以我认为这不是问题。

3. 仅仅因为您向线程池扔了 10 个作业并不意味着它会立即分派 10 个线程来完成工作——您将使用多少线程的决定委托给 .net 和操作系统。