事件如何导致 C# 中的内存泄漏以及弱引用如何帮助缓解这种情况？

Question

据我所知，有两种方法会导致 C# 中无意的内存泄漏：

1. 不处置实现 IDisposable 的资源
2. 错误地引用和取消引用事件。

我实在不明白第二点。如果源对象的生命周期比侦听器长，并且当没有其他引用时侦听器不再需要事件，则使用普通 .NET 事件会导致内存泄漏：源对象在内存中保存侦听器对象应该被垃圾收集。

您能否解释一下事件如何导致 C# 代码中的内存泄漏，以及如何使用弱引用和不使用弱引用进行编码来绕过它？

Answer 1

当侦听器将事件侦听器附加到事件时，源对象将获得对侦听器对象的引用。这意味着在分离事件处理程序或收集源对象之前，垃圾收集器无法收集侦听器。

考虑以下类：

class Source
{
    public event EventHandler SomeEvent;
}

class Listener
{
    public Listener(Source source)
    {
        // attach an event listner; this adds a reference to the
        // source_SomeEvent method in this instance to the invocation list
        // of SomeEvent in source
        source.SomeEvent += new EventHandler(source_SomeEvent);
    }

    void source_SomeEvent(object sender, EventArgs e)
    {
        // whatever
    }
}

...然后是以下代码：

Source newSource = new Source();
Listener listener = new Listener(newSource);
listener = null;

即使我们将 null 分配给 listener，它也不符合垃圾回收的条件，因为 newSource 仍然保留对事件处理程序的引用 (Listener.source_SomeEvent)。要修复这种泄漏，重要的是在不再需要事件侦听器时始终将其分离。

编写上面的示例是为了重点解决泄漏问题。为了修复该代码，最简单的方法可能是让 Listener 保留对 Source 的引用，以便稍后可以分离事件侦听器：

class Listener
{
    private Source _source;
    public Listener(Source source)
    {
        _source = source;
        // attach an event listner; this adds a reference to the
        // source_SomeEvent method in this instance to the invocation list
        // of SomeEvent in source
        _source.SomeEvent += source_SomeEvent;
    }

    void source_SomeEvent(object sender, EventArgs e)
    {
        // whatever
    }

    public void Close()
    {
        if (_source != null)
        {
            // detach event handler
            _source.SomeEvent -= source_SomeEvent;
            _source = null;
        }
    }
}

然后调用代码可以发出信号表明它已使用该对象完成，这将删除 Source 对“Listener”的引用；

Source newSource = new Source();
Listener listener = new Listener(newSource);
// use listener
listener.Close();
listener = null;

Answer 2

阅读 Jon Skeet 关于事件的精彩文章。这不是经典意义上的真正的“内存泄漏”，而更多的是尚未断开连接的保留引用。因此，请始终记住 -= 一个您在之前的点 += 的事件处理程序，您应该是黄金。

Answer 3

严格来说，托管 .NET 项目的“沙箱”内不存在“内存泄漏”。只有引用的保留时间比开发人员认为必要的时间长。弗雷德里克有权利这么做；当您将处理程序附加到事件时，因为处理程序通常是实例方法（需要实例），所以只要维护此引用，包含侦听器的类的实例就会保留在内存中。如果侦听器实例依次包含对其他类的引用（例如，对包含对象的反向引用），则在侦听器超出所有其他范围后，堆可能会保持相当大的时间。

也许对 Delegate 和 MulticastDelegate 有更多深奥知识的人可以对此有所了解。在我看来，如果满足以下所有条件，则可能存在真正的泄漏：

• 事件侦听器需要通过实现 IDisposable 来释放外部/非托管资源，但它要么不这样做，要么
• 事件多播委托不调用其重写的 Finalize() 方法中的 Dispose() 方法，并且
• 包含事件的类不会通过其自己的 IDisposable 实现或在 Finalize() 中调用委托的每个 Target 上的 Dispose()。

我从未听说过任何涉及在委托目标上调用 Dispose() 的最佳实践，更不用说事件侦听器了，因此我只能假设 .NET 开发人员知道他们在这种情况下在做什么。如果这是真的，并且事件背后的 MulticastDelegate 尝试正确处置侦听器，那么所需要做的就是在需要处置的侦听类上正确实现 IDisposable。