您应该知道的5种避免C＃.NET中事件造成的内存泄漏的技术

最新推荐文章于 2024-05-01 19:40:58 发布

风神.NET

最新推荐文章于 2024-05-01 19:40:58 发布

阅读量926

点赞数

分类专栏： NET Core跨平台+CoreCLR+C# 文章标签： c语言 .net wpf

原文链接：https://blog.csdn.net/WuLex

版权

NET Core跨平台+CoreCLR+C# 专栏收录该内容

192 篇文章 38 订阅

订阅专栏

C＃（通常是.NET）中的事件注册是内存泄漏的最常见原因。至少从我的经验来看。实际上，我从事件中看到了太多的内存泄漏，因此在代码中看到 + = 将立即使我感到怀疑。

尽管事件很常见，但它们也很危险。如果您不知道要查找的内容，则事件很容易导致内存泄漏。在本文中，我将解释此问题的根本原因，并提供几种最佳实践技术来解决该问题。最后，我将向您展示一个简单的技巧，以找出您是否确实存在内存泄漏。

了解内存泄漏

在垃圾收集环境中，术语“内存泄漏”有点反直觉。当有一个垃圾收集器负责收集所有内容时，我的内存如何泄漏？

答案是，在存在垃圾收集器（GC）的情况下，内存泄漏表示有些对象仍在引用中，但实际上未被使用。由于已引用它们，因此GC将不会收集它们，并且它们将永久保存，占用内存。

让我们来看一个例子：

public class WiFiManager
{
    public event EventHandler <WifiEventArgs> WiFiSignalChanged;
    // ...
}

public class MyClass
{
    public MyClass(WiFiManager wiFiManager)
    {
        wiFiManager.WiFiSignalChanged += OnWiFiChanged;
    }
 
    private void OnWiFiChanged(object sender, WifiEventArgs e)
    {
        // do something
    }

public void SomeOperation(WiFiManager wiFiManager)
{
    var myClass = new MyClass(wiFiManager);
    myClass.DoSomething();
    
    //... myClass is not used again
}

在此示例中，我们假设WiFiManager 在程序的整个生命周期中都处于活动状态。执行SomeOperation之后，将创建MyClass的实例，并且不再使用它。程序员可能会认为GC将收集它，但事实并非如此。所述WiFiManager保持在其事件MyClass的参考 WiFiSignalChanged和它引起了内存泄漏。GC将永远不会收集MyClass。

1.确保退订

显而易见的解决方案（尽管并非总是最简单的）是记住从事件中注销事件处理程序。一种方法是实现IDisposable：

public class MyClass : IDisposable
{
    private readonly WiFiManager _wiFiManager;
 
    public MyClass(WiFiManager wiFiManager)
    {
        _wiFiManager = wiFiManager;
        _wiFiManager.WiFiSignalChanged += OnWiFiChanged;
    }
 
    public void Dispose()
    {
        _wiFiManager.WiFiSignalChanged -= OnWiFiChanged;
    }
 
    private void OnWiFiChanged(object sender, WifiEventArgs e)
    {
        // do something
    }

当然，您必须确保调用 Dispose 。如果您有WPF控件，一个简单的解决方案是退订 Unloaded 事件。

public partial class MyUserControl : UserControl
{
    public MyUserControl(WiFiManager wiFiManager)
    {
        InitializeComponent();
        this.Loaded += (sender, args) => wiFiManager.WiFiSignalChanged += OnWiFiChanged;
        this.Unloaded += (sender, args) => wiFiManager.WiFiSignalChanged -= OnWiFiChanged;
    }
 
    private void OnWiFiChanged(object sender, WifiEventArgs e)
    {
        // do something
    }
}

优点：简单易读的代码。
缺点：您很容易忘记取消订阅，或者在所有情况下都不会取消订阅，这将导致内存泄漏。

注意：并非所有事件注册都会导致内存泄漏。注册到将要过期的事件时，不会发生内存泄漏。例如，在WPF UserControl中，您可以注册到Button的Click事件。这很好，并且不需要注销，因为用户控件是唯一引用该`Button`的控件。如果没有一个人引用用户控件，那么也将没有一个人引用按钮，并且GC将同时收集两者。

2.让处理程序退订

在某些情况下，您可能希望事件处理程序仅发生一次。在这种情况下，您将希望代码自己退订。当事件处理程序是命名方法时，它很容易：

public class MyClass
{
    private readonly WiFiManager _wiFiManager;
 
    public MyClass(WiFiManager wiFiManager)
    {
        _wiFiManager = wiFiManager;
        _wiFiManager.WiFiSignalChanged += OnWiFiChanged;
    }
 
    private void OnWiFiChanged(object sender, WifiEventArgs e)
    {
        // do something
        _wiFiManager.WiFiSignalChanged -= OnWiFiChanged;
    }
}

但是，有时您希望事件处理程序是lambda表达式。在这种情况下，以下是一种使自己退订的有用技术：

public class MyClass
{
    public MyClass(WiFiManager wiFiManager)
    {
        var someObject = GetSomeObject();
        EventHandler<WifiEventArgs> handler = null;
        handler = (sender, args) =>
        {
            Console.WriteLine(someObject);
            wiFiManager.WiFiSignalChanged -= handler;
        };
        wiFiManager.WiFiSignalChanged += handler;
    }
}

在上面的示例中，lambda表达式非常有用，因为您可以捕获局部变量someObject，而使用处理程序方法则无法做到这一点。

**优点：**简单，易读，只要您确定事件至少会触发一次，就不会发生内存泄漏。

**缺点：**仅在需要处理一次事件的特殊情况下可用。

3.将弱事件与事件聚合器一起使用

在.NET中引用对象时，您基本上会告诉GC该对象正在使用中，因此请不要收集它。有一种引用对象的方法，而无需实际说“我正在使用它”。这种参考称为 弱参考。您是说“我不需要它，但是如果它仍然存在，那么我会使用它”。在其他换句话说，如果某个对象仅被弱引用引用，则GC会收集该对象并释放该内存。这是使用.NET的WeakReference 类实现的。

我们可以通过多种方式使用它来防止内存泄漏。一种流行的设计模式是使用事件聚合器。这个概念是，任何人都可以订阅 T类型的事件，任何人都可以发布 T类型的事件。因此，当一个类发布事件时，将调用所有订阅的事件处理程序。事件聚合器使用WeakReference引用所有内容。所以即使有物体提斯订阅事件，仍然可以对其进行垃圾回收。

这是一个使用Prism 流行的事件聚合器（通过NuGet Prism.Core提供）的示例。

public class WiFiManager
{
    private readonly IEventAggregator _eventAggregator;
 
    public WiFiManager(IEventAggregator eventAggregator)
    {
        _eventAggregator = eventAggregator;
    }
 
    public void PublishEvent()
    {
        _eventAggregator.GetEvent<WiFiEvent>().Publish(new WifiEventArgs());
    }

public class MyClass
{
    public MyClass(IEventAggregator eventAggregator)
    {
        eventAggregator.GetEvent<WiFiEvent>().Subscribe(OnWiFiChanged);
 
    }
 
    private void OnWiFiChanged(WifiEventArgs args)
    {
        // do something
    }

public class WiFiEvent : PubSubEvent<WifiEventArgs>
{
    // ...
}

优点： 防止内存泄漏，相对易于使用。

缺点：

充当所有事件的全局容器。任何人都可以订阅任何人。这使得系统在过度使用时难以理解。没有分离的关注点。

4.对常规事件使用弱事件处理程序

借助一些代码技巧，可以将弱引用与常规事件一起使用。这可以通过几种不同的方式来实现。这是使用Paul Stovell的WeakEventHandler的示例：

public class MyClass
{
    public MyClass(WiFiManager wiFiManager)
    {
        wiFiManager.WiFiSignalChanged += new WeakEventHandler<WifiEventArgs>(OnWiFiChanged).Handler;
    }
 
    private void OnWiFiChanged(object sender, WifiEventArgs e)
    {
        // do something
    }
}

public class WiFiManager
{
    public event EventHandler<WifiEventArgs> WiFiSignalChanged;
    // ...

public void SomeOperation(WiFiManager wiFiManager)
{
    var myClass = new MyClass(wiFiManager);
    myClass.DoSomething();
    
    //... myClass is not used again
}

我真的很喜欢这种方法，因为在我们的案例中，发布者WiFiManager保留了标准的C＃事件。这只是这种模式的一种实现，但是实际上有很多方法可以解决。Daniel Grunwald写了一篇有关不同实现及其差异的文章。

**优点：**利用标准事件。简单。没有内存泄漏。关注点分离（与事件聚合器不同）。

缺点：此模式的不同实现有一些细微之处和不同问题。该示例中的实现实际上创建了一个注册的包装对象，该包装对象从未被GC收集。其他实现可以解决此问题，但还有其他问题，例如其他样板代码。在Daniel的文章中了解有关此内容的更多信息。

`WeakReference`解决方案存在的问题

使用WeakReference意味着GC将能够在可能的情况下收集订阅类。但是，GC不会立即收集未引用的对象。就开发者而言，它是随机的。因此，对于弱事件，您可能会在当时不应该存在的对象中调用事件处理程序。

事件处理程序可能会执行无害的操作，例如更新内部状态。或者，它可能会更改程序状态，直到GC决定随机收集某个时间为止。这种行为确实很危险。在“弱事件模式是危险的”中对此进行附加阅读。

5.在没有内存探查器的情况下检测内存泄漏

此技术是为了测试现有的内存泄漏，而不是编码模式以首先避免它们。

假设您怀疑某个类存在内存泄漏。如果您有创建一个实例然后希望GC收集它的情况，则可以轻松地确定是否将收集您的实例或是否存在内存泄漏。按着这些次序：

1.将终结器添加到您的可疑类中，并在其中放置一个断点：

2. 在场景开始时添加以下要调用的魔术3行：

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

这将迫使GC到目前为止收集所有未引用的实例（不在生产环境中使用），因此它们不会干扰我们的调试。

3.添加相同的3条魔术代码行，以在方案之后运行。请记住，该方案是创建并收集可疑对象的方案。

4.运行有问题的方案。

在第1步中，我告诉您在类的终结器中放置一个断点。在第一个垃圾回收完成之后，您实际上应该注意该断点。否则，您可能会被废弃旧实例感到困惑。需要注意的重要时刻是您的方案之后调试器是否在Finalizer中停止。

它还有助于在类的构造函数中放置一个断点。这样，您可以计算创建次数和完成次数。如果触发了终结器中的断点，则GC会收集您的实例，一切正常。如果没有，则可能发生内存泄漏。

这是我调试的一种方案，该方案使用了上一种技术中的WeakEventHandler，并且没有内存泄漏：

https://michaelscodingspot.com/wp-content/uploads/2018/12/my-class-is-finalized-with-weakEventHandler.mp4

这是我使用常规事件注册的另一种情况，它确实存在内存泄漏：

https://michaelscodingspot.com/wp-content/uploads/2018/12/my-class-is-not-finalized-with-regular-event.mp4

摘要

总是让我感到惊讶的是，C＃看起来像是一种易于学习的语言，并且提供了一个提供训练平台的环境。但实际上，还远远没有做到。诸如使用事件之类的简单事情，可以由未经培训的手轻松地将您的应用程序变成一堆内存泄漏。

至于在代码中使用的正确模式，我认为本文的结论应该是，在所有情况下都没有正确答案。提供的所有技术，以及他们，视情况而定是可行的解决方案。

原来这是一个相对较大的职位，但在此问题上，我仍然处于较高水平。这恰恰证明了在这些问题上存在多少深度，以及软件开发如何永无止境。

风神.NET

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
您应该知道的5种避免C＃.NET中事件造成的内存泄漏的技术

C＃（通常是.NET）中的事件注册是内存泄漏的最常见原因。至少从我的经验来看。实际上，我从事件中看到了太多的内存泄漏，因此在代码中看到 + = 将立即使我感到怀疑。尽管事件很常见，但它们也很危险。如果您不知道要查找的内容，则事件很容易导致内存泄漏。在本文中，我将解释此问题的根本原因，并提供几种最佳实践技术来解决该问题。最后，我将向您展示一个简单的技巧，以找出您是否确实存在内存泄漏。了解内存泄漏在垃圾收集环境中，术语“内存泄漏”有点反直觉。当有一个垃圾收集器负责收集所有内容时，我的内存如何泄漏？答案
复制链接

扫一扫