使用 filesystemwatcher 清理的 .net 事件处理程序
我使用 .net FileSystemWatcher 类编写了一个简单的测试工具。问题是我遇到了内存泄漏,因为 FileSystemWatcher 中更改的处理程序引用了 MemoryLeakTest 的实例。清理此引用以便垃圾收集器随后可以收集 MemoryLeakTest 实例和 FileSystemWatcher 实例的正确方法是什么?
要查看堆上泄漏的实例,请按照以下说明操作: http://blogs.msdn.com/b/calvin_hsia /archive/2008/04/11/8381838.aspx
预先感谢您的建议
using System;
using System.IO;
namespace MemoryLeakTest {
class Leaking {
private FileSystemEventHandler changedHandler;
private FileSystemWatcher fsw;
public Leaking() {
changedHandler = new FileSystemEventHandler(fsw_Changed);
fsw = new FileSystemWatcher("c:\\", "*.*");
fsw.Changed += changedHandler;
fsw.EnableRaisingEvents = true;
}
~Leaking() {
fsw.Changed -= changedHandler;
fsw.Dispose();
}
void fsw_Changed(object sender, FileSystemEventArgs e) {
Console.WriteLine("Changed");
}
}
class Program {
static void Main(string[] args) {
for (int i = 0; i < 100; ++i) {
var x = new Leaking();
}
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.ReadLine();
}
}
}
I've writte a simple test tool using the .net FileSystemWatcher class. The problem is I got a memory leak because instances of MemoryLeakTest are referenced by the changed handler in the FileSystemWatcher. What would be the correct way of cleaning up this reference so that the garbage collector could afterwards collect the MemoryLeakTest instance and the FileSystemWatcher instance?
To see the leaked instances on the heap follow this instructions:
http://blogs.msdn.com/b/calvin_hsia/archive/2008/04/11/8381838.aspx
Thanks in advance for your advice
using System;
using System.IO;
namespace MemoryLeakTest {
class Leaking {
private FileSystemEventHandler changedHandler;
private FileSystemWatcher fsw;
public Leaking() {
changedHandler = new FileSystemEventHandler(fsw_Changed);
fsw = new FileSystemWatcher("c:\\", "*.*");
fsw.Changed += changedHandler;
fsw.EnableRaisingEvents = true;
}
~Leaking() {
fsw.Changed -= changedHandler;
fsw.Dispose();
}
void fsw_Changed(object sender, FileSystemEventArgs e) {
Console.WriteLine("Changed");
}
}
class Program {
static void Main(string[] args) {
for (int i = 0; i < 100; ++i) {
var x = new Leaking();
}
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.ReadLine();
}
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您还可能会遇到 FileWatcher 本身的内存泄漏问题。请参阅以下内容: http://connect .microsoft.com/VisualStudio/feedback/details/565720/memory-leak-in-system-io-filesystemwatcher
You may also be running into a memory leak in the FileWatcher itself. See the following: http://connect.microsoft.com/VisualStudio/feedback/details/565720/memory-leak-in-system-io-filesystemwatcher
是的,您应该在每个具有实现
IDisposable
成员的类中实现IDisposable
。请参阅 http://msdn.microsoft.com/en -us/library/b1yfkh5e(v=VS.100).aspx。然而,实现
IDisposable
只是确保及时清理资源。通常,未能实现 IDisposable 不会导致长期内存泄漏,因为垃圾收集器最终会运行终结器,而这些终结器将释放操作系统资源。但不处理可能会导致短期内存泄漏和资源耗尽。它可能导致长期问题,但在使用 BCL 对象时这种情况相对不常见。例如,在上面的测试程序中,一旦退出循环,您创建的 Leaking 对象就“无根”,并且正如您所见,垃圾收集器确实会收集它们。如果你让你的程序运行一段时间,做其他事情,这些对象将在下一次垃圾收集期间被收集。这是短期内存和资源泄漏,但不是长期问题。
现在,如果出现以下情况,您可能会遇到内存泄漏:
在这种情况下,
观察者
保存对每个创建的对象的引用。由于watcher
已获得 root 权限,因此这些对象将保持活动状态。它们不会被垃圾收集。解决此问题的唯一方法是确保对象将自身从事件通知中删除。您可以在对象的
Dispose
方法中执行此操作,但也有其他方法。但是,您必须小心不要在终结器中执行此操作。请记住,终结器没有按固定顺序运行。观察者有可能在引用它的对象之前完成(因为两者都不是根对象,所以完成顺序并不重要)。这就是Dispose(bool)
方法存在的原因:防止您在终结期间访问其他对象。这是你的选择。您可以编写一个
Dispose
方法来从事件通知中删除该对象,或者您可以确保编写在对象不再对事件感兴趣时执行删除操作的代码。在Dispose
中执行此操作的缺点是执行订阅的对象必须维护对引发事件的对象的引用。Yes, you should implement
IDisposable
in every class that has a member that implementsIDisposable
. See http://msdn.microsoft.com/en-us/library/b1yfkh5e(v=VS.100).aspx.However, implementing
IDisposable
just makes sure that resources are cleaned up in a timely manner. Typically, failure to implementIDisposable
won't result in a long-term memory leak because the garbage collector will eventually get around to running the finalizers, and those will release the operating system resources. But not disposing can cause short-term memory leaks and resource exhaustion. It can cause a long-term problem, but that's relatively uncommon when working with BCL objects.For example, in your test program above, the
Leaking
objects that you create are "rootless" once you exit the loop, and as you saw the garbage collector does collect them. If you were to let your program run for a while, doing other things, those objects would be collected during the next garbage collection. It's a short-term memory and resource leak, but not a long-term problem.Now, you could run into a memory leak if you have something like:
In this case, the
watcher
holds a reference to each of the created objects. And sincewatcher
is rooted, those objects will remain active. They won't be garbage collected.The only way to fix this is to ensure that the object removes itself from the event notification. You can do that in the object's
Dispose
method, although there are other ways, too. However, you have to be careful not to do that in the finalizer. Remember that finalizers run in no set order. It's possible that thewatcher
was finalized before the object that references it (since neither is rooted, finalization order doesn't matter). That's why theDispose(bool)
method exists: to prevent you from accessing other objects during finalization.It's your choice. You can write a
Dispose
method that removes the object from the event notification, or you can be sure to write code that does the removal when the object is no longer interested in the event. The drawback to doing this inDispose
is that the object doing the subscribing has to maintain a reference to the object that's raising the events.