C# 线程池设计问题

我有一个设计问题。我希望得到一些反馈，以了解线程池是否适合我正在编写的客户端程序

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

我预计建立的连接不会超过10-25个。一旦传输队列为空，程序将简单地等待，直到队列中再次出现记录

线程池是一个很好的选择，还是我应该使用不同的方法

---

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

根据您的描述，听起来threadpool非常适合

问题：

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

在以前的阅读中，当应用程序可能正在等待不完整的连接（如web应用程序）时，将线程池与长时间运行的任务捆绑在一起可能是不好的。不过，听起来您有一个专用的windows服务正在运行，所以我认为这不是一个问题

仅仅因为您在线程池中抛出了10个作业，并不意味着它将立即分派10个线程来完成这项工作——您正在将使用多少线程的决定权委托给.net和o/s

---

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

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

MSDN主题“”为何时不使用线程池线程提供了良好的指导原则：

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

• 你需要一个前台线程
• 您需要一个线程具有特定的优先级
• 您的任务会导致线程长时间阻塞。这个 线程池的最大数目为 线程，所以大量阻塞 线程池线程可能会阻止 从一开始就完成任务
• 您需要将线程放置到单线程单元中。全部的 线程池线程位于 多线程单元
• 您需要有一个与线程关联的稳定标识，或者 将线程专用于任务

---

线程池会很好，因为它允许您集中精力设置排队到线程的作业，而不用担心初始化和清理单个线程

---

但是你想让它怎么工作？您是要为一台主机将多个作业排队到池中，还是要为每台主机提供一个从其自己的队列读取作业的线程

队列只有一个数据库表，并且有一个按机器名排列的列。客户端服务将按其自己的计算机名进行查询。然后，从该记录子集（假设返回100条记录）中，它将按主机分组（假设它在100条记录的集合中返回了4个唯一主机）。因此，我希望为每个主机启动池中的4个线程。感谢您的输入。你建议我自己创建线程并管理它们吗？事实上，从长远来看，创建线程并自己管理它们是一条路。与FTP传输时间相比，线程加速的成本微不足道，FTP传输时间是线程池的主要好处之一（另一个好处是简化的接口

QueueUserWorkItem

提供）。+1同意您的所有推理，线程池非常适合。