多个FileSystemWatcher好主意？

Question

我正在编写一个迷你编辑器组件，它非常像Notepad ++或UltraEdit，需要监控用户打开的文件 - 它有点粘，但这就是它需要的方式。

使用FileSystemWatcher的多个实例来监视打开的文件是否明智 - 再次像Notepad ++或UltraEdit那样或者有更好的方法来管理它们吗？

文件关闭后，它们将被妥善处理。

对不起，还有一件事，为驱动器和监视器创建一个通用的FileSystemWatcher是否更明智，然后只有在我知道正确的文件后才向他们显示重新加载文件的消息？或者是那个被重新启动的？

Answer 1

你不会遇到多个FileSystemWatchers的问题，而且实际上没有任何其他方法可以解决这个问题。

为了提高性能，请务必指定为您可以使用的窄过滤器。

Answer 2

FileSystemWatcher有一个缺点，它会锁定监视文件夹，因此，例如，如果您正在观看可移动存储上的文件，则会阻止“安全删除设备”。

您可以尝试通过SHChangeNotifyRegister使用Shell通知。在这种情况下，您将有一个入口点用于所有更改（如果您愿意，还有几个），但在这种情况下，您将需要一些本机shell互操作。

Answer 3

这取决于可能的用例。

如果用户打算在同一目录中打开多个文件，并且可能不会修改任何其他文件，那么如果文件数量很大，那么该目录的单个观察者可能不会比每个文件一个文件更麻烦。

您将发现的唯一方法是通过基准测试。当然，每个文件执行一次会使观察者的生命周期变得更加简单，因此这应该是您的第一种方法。请注意，观察者在系统线程池中触发它们的事件，因此多个观察者可以同时触发（可能影响您设计的事物）

我当然不会为每个驱动器做一个观察者，即使采用积极的过滤方式，你也会采取更多的努力。

Answer 4

如果必须，可以使用多个观察者。正如ShuggyCoUk所说，如果所有文件都在同一个文件夹中，你可以通过将文件观察者合并为一个进行优化。

在更高的文件夹（例如驱​​动器的根目录）上创建文件监视器可能是不明智的，因为现在您的代码必须处理从文件系统中发生的其他更改触发的更多事件，并且它相当容易如果您的代码不够快，无法处理事件，请进入缓冲区溢出。

较少文件观察者的另一个论点，文件系统观察者是本机对象，它引导内存。因此，根据应用程序的生命周期和大小，您可能会遇到内存碎片问题：

每当您打开文件时，您的代码会运行很长时间（例如数小时或数天），它会在内存中创建一些数据块并实例化文件观察程序。然后你清理这个临时数据，但是文件监视器仍然存在，如果你多次重复（并且不关闭文件，或者忘记处理观察者），你刚刚在虚拟内存中创建了多个无法由CLR移动的对象，并可能导致内存拥塞。请注意，如果您有一些观察者，这不是什么大问题，但如果您怀疑自己可能会遇到数百或更多，请注意这将成为一个主要问题。