原文来自互联网,由长沙DotNET技术社区编译。
5种避免C#.NET中事件造成的内存泄漏的技术
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 类实现的。
我们可以通过多种方式使用它来防止内存泄漏。一种流行的设计模式是使用事件聚合器[1]。这个概念是,任何人都可以订阅 T类型的事件,任何人都可以发布 T类型的事件。因此,当一个类发布事件时,将调用所有订阅的事件处理程序。事件聚合器使用WeakReference引用所有内容。所以即使有物体提斯 订阅事件,仍然可以对其进行垃圾回收。
这是一个使用Prism 流行的事件聚合器(通过NuGet Prism.Core提供[2])的示例[3]。
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[4]的示例:
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写了一篇[5]有关不同实现及其差异的文章。
优点:利用标准事件。简单。没有内存泄漏。关注点分离(与事件聚合器不同)。
缺点:此模式的不同实现有一些细微之处和不同问题。该示例中的实现实际上创建了一个 注册的包装对象,该 包装对象从未被GC收集。其他实现可以解决此问题,但还有其他问题,例如其他样板代码。在Daniel的文章中[6]了解有关此内容的更多信息 。
WeakReference解决方案存在的问题
使用WeakReference意味着GC将能够在可能的情况下收集订阅类。但是,GC不会立即收集未引用的对象。就开发商而言,它是随机的。因此,对于弱事件,您可能会在当时不应该存在的对象中调用事件处理程序。
事件处理程序可能会执行无害的操作,例如更新内部状态。或者,它可能会更改程序状态,直到GC决定随机收集某个时间为止。这种行为确实很危险。在“弱事件模式是危险的”中[7]对此进行附加阅读 。
5.在没有内存探查器的情况下检测内存泄漏
此技术是为了测试现有的内存泄漏,而不是编码模式以首先避免它们。
假设您怀疑某个类存在内存泄漏。如果您有创建一个实例然后希望GC收集它的情况,则可以轻松地确定是否将收集您的实例或是否存在内存泄漏。按着这些次序:
1.将终结器添加到您的可疑类中,并在其中放置一个断点:
1.在场景开始时添加以下要调用的魔术3行:
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
这将迫使GC到目前为止收集所有未引用的实例(不在生产环境中使用),因此它们不会干扰我们的调试。
3.添加相同的3条魔术代码行,以 在方案之后运行。请记住,该方案是创建并收集可疑对象的方案。
4.运行有问题的方案。
在第1步中,我告诉您在类的终结器中放置一个断点。在第一个垃圾回收完成之后,您实际上应该注意该断点。否则,您可能会被废弃旧实例感到困惑。需要注意的重要时刻是 您的方案之后调试器是否在Finalizer中停止 。
它还有助于在类的构造函数中放置一个断点。这样,您可以计算创建次数和完成次数。如果触发了终结器中的断点,则GC会收集您的实例,一切正常。如果没有,则可能发生内存泄漏。
这是我调试的一种方案,该方案使用了上一种技术中的WeakEventHandler,并且没有内存泄漏:
这是我使用常规事件注册的另一种情况,它确实存在内存泄漏:
摘要
总是让我感到惊讶的是,C#看起来像是一种易于学习的语言,并且提供了一个提供训练平台的环境。但实际上,还远远没有做到。诸如使用事件之类的简单事情,可以由未经培训的手轻松地将您的应用程序变成一堆内存泄漏。
至于在代码中使用的正确模式,我认为本文的结论应该是,在所有情况下都没有正确答案。提供的所有技术,以及他们, 视情况而定是可行的解决方案。
原来这是一个相对较大的职位,但在此问题上,我仍然处于较高水平。这恰恰证明了在这些问题上存在多少深度,以及软件开发如何永无止境。
有关内存泄漏的更多信息,请查看我的文章查找,修复和避免C#.NET:8最佳实践中的内存泄漏[8]。从我自己的经验和其他高级.NET开发人员那里获得的大量信息都为我提供了建议。它包括有关内存分析器,非托管代码的内存泄漏,监控内存等信息。
我希望您在评论部分中留下一些反馈。并确保订阅[9]博客并收到新帖子通知。
References
[1]
事件聚合器: https://www.codeproject.com/Articles/812461/Event-Aggregator-Pattern[2]
Prism.Core提供: https://www.nuget.org/packages/Prism.Core/[3]
示例: https://www.nuget.org/packages/Prism.Core/[4]
WeakEventHandler: http://paulstovell.com/blog/weakevents[5]
一篇: https://www.codeproject.com/Articles/29922/Weak-Events-in-C[6]
文章中: https://www.codeproject.com/Articles/29922/Weak-Events-in-C[7]
“弱事件模式是危险的”中: https://ladimolnar.com/2015/09/14/the-weak-event-pattern-is-dangerous/[8]
查找,修复和避免C#.NET:8最佳实践中的内存泄漏: https://michaelscodingspot.com/2019/01/03/find-fix-and-avoid-memory-leaks-in-c-net-8-best-practices/[9]
订阅: https://michaelscodingspot.com/subscribe/