多个 FileSystemWatcher 是个好主意吗？
我正在编写一个迷你编辑器组件，它很像 Notepad++ 或 UltraEdit，需要监视用户打开的文件 - 它有点粘糊糊，但这就是它需要的方式。
使用 FileSystemWatcher 的多个实例来监视打开的文件是否明智 - 再次像 Notepad++ 或 UltraEdit 或者是否有更好的方法来管理这些文件？
文件关闭后，它们将得到妥善处置。
抱歉，另一件事是，为驱动器创建一个通用 FileSystemWatcher 并对其进行监视，然后仅在我知道其文件正确后才向他们显示一条重新加载文件的消息，这是否会更明智？ 还是说已经恢复了？
I'm writing a mini editor component that is much like Notepad++ or UltraEdit that needs to monitor the files the users open - its a bit slimy, but thats the way it needs to be.
Is it wise to use multiple instances of FileSystemWatcher to monitor the open files - again like Notepad++ or UltraEdit or is there a better way to manage these?
They'll be properly disposed once the document has been closed.
Sorry, one other thing, would it be wiser to create a generic FileSystemWatcher for the drive and monitor that, then only show them a message to reload the file once I know its the right file? Or is that retarted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您不会遇到多个 FileSystemWatchers 的问题，并且确实没有任何其他方法可以解决此问题。
为了提高性能，请确保指定尽可能窄的过滤器。
You're not going to run into problems with multiple FileSystemWatchers, and there really isn't any other way to pull this off.
For performance, just be sure to specify as narrow filters as you can get away with.
FileSystemWatcher 有一个缺点，它会锁定监视的文件夹，因此，例如，如果您正在监视可移动存储上的文件，它会阻止“安全设备删除”。
您可以尝试通过 SHChangeNotifyRegister 使用 Shell 通知。 在这种情况下，您将拥有一个用于所有更改的入口点（如果您愿意，也可以有多个入口点），但在这种情况下，您将需要一些本机 shell 互操作。
FileSystemWatcher have a drawback, it locks watched folder, so, for example, if you are watching file on removable storage, it prevent "safe device removal".
You can try using Shell Notifications via SHChangeNotifyRegister. In this case you will have one entry point for all changes (or several if you want to), but in this case you will need some native shell interop.
这取决于可能的用例。
如果用户要打开同一目录中的多个文件，并且可能不修改任何其他内容，那么如果文件数量很大，则该目录的单个监视程序可能比每个文件一个监视程序更轻松。
您找到答案的唯一方法是通过基准测试。 当然，每个文件执行一个操作会使观察者的生命周期变得更加简单，因此这应该是您的第一种方法。 请注意，观察程序在系统线程池上触发事件，因此多个观察程序可以同时触发（这可能会影响您的设计）
我当然不会为每个驱动器执行一个观察程序，即使这样您也会付出更多的努力具有积极的过滤功能。
It depends on the likely use cases.
If a user is going to open several files in the same directory and likely not modify anything else a single watcher for that directory may be less onerous than one per file if the number of files is large.
The only way you will find out is by benchmarking. Certainly doing one per file makes the lifespan of the watcher much simpler so that should be your first approach. Note that the watchers fire their events on a system thread pool, so multiple watchers can fire at the same time (something that may influence you design)
I certainly wouldn't do a watcher per drive, you will cause far more effort that way even with aggressive filtering.
如果有必要的话，使用多个观察者是可以的。 正如 ShuggyCoUk 评论所说，如果所有文件都位于同一文件夹中，则可以通过将文件观察器合并为一个来进行优化。
在更高的文件夹（例如驱动器的根目录）上创建文件观察器可能是不明智的，因为现在您的代码必须处理由文件系统中发生的其他更改引发的更多事件，并且很容易进入缓冲区如果您的代码速度不够快，无法处理事件，则会发生溢出。
less 文件观察器的另一个论点是，文件系统观察器是一个本机对象，它固定内存。 因此，根据应用程序的生命周期和大小，您可能会遇到内存碎片问题，如下所示：
每当您打开文件时，代码都会运行很长时间（例如几小时或几天），它会在内存中创建一些数据块，并且实例化一个文件观察器。 然后你清理这个临时数据，但文件观察器仍然存在，如果你重复多次（并且没有关闭文件，或者忘记处置观察器），你只是在虚拟内存中创建了多个不能被 CLR 移动的对象，并且可能会陷入内存拥塞。 请注意，如果您周围有几个观察者，这并不是什么大问题，但如果您怀疑自己可能有数百人或更多，请注意这将成为一个主要问题。
Using multiple watcher is fine if you have to. As the comment ShuggyCoUk says, you can optimize by combining file watchers into one if all your files are in the same folder.
It's probably unwise to create a file watcher on a much higher folder (e.g. the root of the drive), because now your code has to handle many more events firing from other changes happening in the file system, and it's fairly easy to get into buffer overflow if your code is not fast enough to handle the events.
Another argument for less file watcher, a filesystemwatcher is a native object, and it pins memory. So depending on the life span and size of your app, you might get into memory fragmentation issues here is how:
Your code runs for a long time (e.g. hours or days) whenever you open a file it create some chunk of data in memory and instantiates a file watcher. You then cleanup this temporary data but the file watcher is still there, IF you repeat that multiple times (and not close the files, or forget to dispose the watchers) you just created multiple objects in virtual memory that cannot be moved by the CLR, and can potentially get into memory congestion. Note that this is not a big deal if you have a few watchers around, but if you suspect you might get into the hundreds or more, beware that's going to become a major issue.