FileSystemWatcher 触发后 - 线程池还是专用线程？答案

【问题标题】：After FileSystemWatcher fires - Thread Pool or Dedicated thread?FileSystemWatcher 触发后 - 线程池还是专用线程？
【发布时间】：2010-02-22 00:55:40
【问题描述】：

我即将实现原型 FileSystemWatcher 解决方案。我有一个目录来监视文件的创建，以及吸收创建的文件并将其插入数据库的任务。粗略地说，这将涉及读取和处理 6 或 7、80 个字符文本文件，这些文件以 150 毫秒的速度出现，每隔几秒就会出现一次，很少需要处理 2MB 的二进制文件。这很可能是一个 24/7 的流程。

根据我对 FileSystemWatcher 对象的了解，最好将其事件排入一个线程中，然后在另一个线程中将它们出列/处理。我现在的困惑是执行处理的线程的更好创建机制是什么。我可以看到的选择是：

每次收到 FSW 事件时，我都会手动创建一个新线程（是的，我知道 .. 愚蠢的架构，但我不得不说）。
每当我收到 FSW 事件时，就在 CLR 线程池中进行处理
在启动时，为处理创建一个专用的第二个线程，并使用生产者/消费者模型来处理工作。主线程将请求入队，第二个线程将其出队并执行工作。

我倾向于将第三种方法作为首选方法，因为我知道工作线程总是需要的——而且可能更多，因为我对线程池没有感觉。

【问题讨论】：

标签： c# multithreading threadpool filesystemwatcher

【解决方案1】：

如果您知道总是需要第二个线程，并且您也知道您永远不需要超过一个工作线程，那么选项三很好够了。

【讨论】：

+1，我要补充一点，使用线程池将尝试在多个线程上同时处理您的请求，这对您的应用程序来说听起来不是一件好事。
匿名 .. 从我所做的测试来看，我的处理应该在 150 毫秒内真正地完成，除了二进制文件处理的情况 - 这将在 150 毫秒左右运行，但应该很少见如果事情排队，就会有足够的时间赶上。

【解决方案2】：

第三个选项最符合逻辑。

关于 FSW 丢失一些文件事件，我实现了这个： 1) 在 FileCreate 上触发的 FSW 对象 2) tmrFileCheck, ticks = 5000 (5 秒) - 调用 tmrFileChec_Tick

当FileCreate事件发生时，if (tmrFileCheck.Enabled == false) then tmrFileCheck.Start()

这样，10 秒后 tmrFileCheck_Tick 触发 a) tmrFileCheck.Stop() b) CheckForStragglerFiles

在我运行的测试中，这在每分钟创建

一种变体是每 NN 秒只设置一个计时器，然后扫描目录中的散乱文件。

另一种变体是雇用我按F5刷新窗口并在有散乱文件时给您打电话；只是一个建议。 :-P

【讨论】：

【解决方案3】：

请注意，FileSystemWatcher 可能会错过事件，不能保证它会传递已发生的所有特定事件。您将接收事件的线程完成的工作保持在最低限度的设计应该会减少发生这种情况的机会，但鉴于事件缓冲区大小有限（最高为 64KB），这仍然是一种可能性。

如果您决定使用 FileSystemWatcher，我强烈建议您开发一系列酷刑测试。

在我们的测试中，我们遇到了网络位置的问题，即更改 InternalBufferSize 并没有解决问题，但是当我们遇到这种情况时，我们也没有收到错误事件通知。

因此，我们为此开发了自己的轮询机制，使用Directory.GetFiles，然后将返回文件的状态与之前轮询的状态进行比较，确保我们始终拥有准确的增量。

当然，这会付出巨大的性能代价，这对您来说可能还不够好。

【讨论】：

Leon，我很清楚 FSW 的限制和问题。网络共享似乎并不强大。我只会在本地目录上使用，我不希望 FSW 事件缓冲区大小会给我带来问题。我正在计划一个清扫流程，以防我错过一些东西。
Leon ..顺便说一句，我将计划进行大量测试.. FSW 似乎有大量隐藏的陷阱。
如果我这样做，我会选择 FSW，并时不时地对目录进行一次全面扫描（也许每天，在系统通常安静的时候？）以确保一切被抓住了。