Threadpool设计问题

Question

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

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

我预计不会建立超过10-25个连接。传输队列为空后，程序将一直等到队列中再次有记录。

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

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

Answer 1

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

Ftp转移需要相对较长的时间（即使有合理的超时），因此它们并不适合。您可能能够通过使用线程池获得，但如果您使用它，您可能还会发现自己遇到无法解释的错误。这取决于您的应用程序使用与线程池相关的框架功能（异步委托等）的程度。

MSDN主题“The Managed Thread Pool”为不使用线程池线程提供了很好的指导：

  

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

     

  
• 您需要一个前台线程。
  
• 您需要一个具有特定优先级的线程。
  
• 您的任务导致线程长时间阻塞。该   线程池的最大数量   线程，所以大量被阻止   线程池线程可能会阻止   从开始的任务。
  
• 您需要将线程放入单线程单元中。所有   ThreadPool线程在   多线程公寓。
  
• 您需要拥有与该主题相关联的稳定标识，或者   将线程专用于任务。
  

Answer 2

从你所描述的内容来看，听起来好像是一个线程池。

的问题：

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

2. 在较旧的阅读中，当应用程序可能正在等待正在进行的连接（如Web应用程序）时，使用长期运行任务来绑定线程池可能会很糟糕。但是，听起来你有一个专门的Windows服务运行，所以我不认为这是一个问题。

3. 仅仅因为你在线程池中抛出10个作业并不意味着它会立即调度10个线程来完成工作 - 你委托决定使用多少个线程到.net和o /第

Answer 3

ThreadPool会很好，因为它可以让你专注于设置排队到线程的作业，而不是担心初始化和清理单个线程。

但是你想怎么做呢？您是要将多个作业排队到主机的池中，还是要为每个从其自己的队列中读取作业的主机创建一个线程？