c# - 在 C# 中使用 SFTP 时的线程最佳实践

Question

好的，

这更多是这些“概念性问题”之一，但我希望我能在正确的方向上得到一些指示。首先是所需的场景:

• 我想向 SFTP 服务器查询目录和文件列表
• 我想同时上传或下载文件

使用 Tamir.SharpSsh 提供的 SFTP 类，这两件事都非常容易，但如果我只使用一个线程，它会有点慢。尤其是对子目录的递归变得非常“UI 阻塞”，因为我们谈论的是 10.000 个目录。

我的基本方法很简单，创建某种“池”，在其中保留 10 个打开的 SFTP 连接。然后向第一个工作人员查询目录列表。如果获得此列表，则发送下一个空闲的 worker (例如 1-10，第一个也再次空闲)以获取子目录详细信息。一旦有 worker 空闲，就派他去寻找子目录。等等……

我了解 ThreadPool、简单的线程并进行了一些测试。让我有点困惑的是:我基本上需要......

• 我创建的线程列表，比如说 10
• 将所有线程连接到服务器
• 如果连接断开，创建一个新线程/sftp 客户端
• 如果有工作要做，占用第一个空闲线程并处理工作

我目前不确定实现细节，尤其是“要做的工作”和“维护线程列表”部分。

这是一个好主意:

• 将工作封装在一个对象中，包含工作描述(路径)和回调
• 将线程发送到一个等待 100 毫秒的无限循环中以等待工作
• 如果 SFTP 挂了，要么恢复它，要么杀死整个线程并创建一个新线程
• 如何封装这个，是我自己写“10ThreadsManager”还是有一些出来

好的，到目前为止...

顺便说一句，我也可以使用 PRISM 事件和命令，但我认为问题不相关。也许 EventModel 表示“工作包”的处理已完成...

感谢任何想法，评论家..克里斯

Answer 1

一堆小笔记:

如果您正在使用一些在内部使用线程池的 .NET API，那么您不能进行无限等待，因为操作系统拥有线程池中的线程，这些线程应该“短暂”使用，然后返回给操作系统，这是最稳健的行为。当然，如果您由于长时间运行的处理而最终占用线程池，操作系统可以根据需要增加线程池，但更好的设计是避免这种行为。

如果您在 XP 上运行，您可能还想避免使用 ThreadPool(操作系统级别，因此是 .NET)，因为它在 Vista 和更高版本中已修复/退出，XP 版本被认为不太健壮。

如果您确实使用 ThreadPool，那么您最终会将异步工作排入队列，因为它已经在等待工作完成。

编写自己的 ThreadManager 相当容易，您可以找到很多相关示例，但一如既往，此类事情应尽可能简单。

对于您的第三个要点，恢复 SFTP 连接比终止整个线程要好。如果您终止一个线程(假设您的 ThreadManager 可以处理，当然永远不要终止 OS ThreadPool 中的线程)，那么它首先必须将未处理的作业返回到某个队列，感觉工作太多了。