使用 filesystemwatcher 清理的 .net 事件处理程序

发布于 2024-11-08 18:25:15 字数 1296 浏览 0 评论 0原文

我使用 .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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

邮友 2024-11-15 18:25:15

您还可能会遇到 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

夏末的微笑 2024-11-15 18:25:15

是的,您应该在每个具有实现 IDisposable 成员的类中实现 IDisposable。请参阅 http://msdn.microsoft.com/en -us/library/b1yfkh5e(v=VS.100).aspx

然而,实现IDisposable只是确保及时清理资源。通常,未能实现 IDisposable 不会导致长期内存泄漏,因为垃圾收集器最终会运行终结器,而这些终结器将释放操作系统资源。但不处理可能会导致短期内存泄漏和资源耗尽。它可能导致长期问题,但在使用 BCL 对象时这种情况相对不常见。

例如,在上面的测试程序中,一旦退出循环,您创建的 Leaking 对象就“无根”,并且正如您所见,垃圾收集器确实会收集它们。如果你让你的程序运行一段时间,做其他事情,这些对象将在下一次垃圾收集期间被收集。这是短期内存和资源泄漏,但不是长期问题。

现在,如果出现以下情况,您可能会遇到内存泄漏:

FileSystemWatcher watcher = new FileSystemWatcher(...);
void MakeABigLeak()
{
    for (int i = 0; i < 10; ++i)
    {
        var MyObject = new SomeObject();
        watcher.Changed += MyObject.ChangeHandler;
    }
}

在这种情况下,观察者保存对每个创建的对象的引用。由于watcher 已获得 root 权限,因此这些对象将保持活动状态。它们不会被垃圾收集。

解决此问题的唯一方法是确保对象将自身从事件通知中删除。您可以在对象的 Dispose 方法中执行此操作,但也有其他方法。但是,您必须小心不要在终结器中执行此操作。请记住,终结器没有按固定顺序运行。观察者有可能在引用它的对象之前完成(因为两者都不是根对象,所以完成顺序并不重要)。这就是 Dispose(bool) 方法存在的原因:防止您在终结期间访问其他对象。

这是你的选择。您可以编写一个 Dispose 方法来从事件通知中删除该对象,或者您可以确保编写在对象不再对事件感兴趣时执行删除操作的代码。在 Dispose 中执行此操作的缺点是执行订阅的对象必须维护对引发事件的对象的引用。

Yes, you should implement IDisposable in every class that has a member that implements IDisposable. 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 implement IDisposable 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:

FileSystemWatcher watcher = new FileSystemWatcher(...);
void MakeABigLeak()
{
    for (int i = 0; i < 10; ++i)
    {
        var MyObject = new SomeObject();
        watcher.Changed += MyObject.ChangeHandler;
    }
}

In this case, the watcher holds a reference to each of the created objects. And since watcher 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 the watcher was finalized before the object that references it (since neither is rooted, finalization order doesn't matter). That's why the Dispose(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 in Dispose is that the object doing the subscribing has to maintain a reference to the object that's raising the events.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文