众所周知,内存管理和如何避免内存泄漏(memory leak)一直是软件开发的难题。不要说C、C++等非托管(unmanaged)语言,即使是Java、.NET等托管(managed)语言,尽管有着完善的垃圾回收器(GC),内存泄漏也经常发生。不过,这并非GC的bug或设计缺陷,而是因为在开发时有太多能够导致内存泄漏的方式了,尤其是对于绑定(Binding)、事件(Event)、行为(Behavior)满天飞的WPF/UWP应用。
对于托管类应用,内存泄漏主要可以分为两大类:托管类内存泄漏(managed memory leak)和非托管类内存泄漏(unmanaged memory leak)。
1.托管类内存泄漏(managed memory leak)
这种泄漏发生的根本原因是由于无用的、本该被回收的托管类对象(managed objects)由于被“无意的”(unintended)的引用而导致无法被回收。
这与GC的工作原理有关:在进行垃圾回收时,应用将挂起所有线程,这样GC就可以遍历所有的GC Root对象,并将它们标记为”不可回收“,接着GC进一步将它们所引用的所有对象也都标记为”不可回收“。这个过程将一直递归进行下去,直到无法继续。所有未被标记为”不可回收“的对象都被GC视为垃圾对象,最终都将被回收。简而言之,GC对“无用”对象的识别机制很简单:判断对象是否被“GC Root”对象所引用。
可以被视为GC Root的对象主要包括三大类:
a.正在执行的线程的“活跃”栈(Live Stack of the running threads),包括正在执行的方法的参数、局部变量、寄存器变量等;
b.静态变量(Static variables);
c.通过interop传递给COM对象(其内存回收采用“引用计数”机制)的托管对象
如果一个对象被生存期更长的对象(例如全局对象或静态类)所引用,那么在进行GC时,即使它已经不会再被用到,也会被标记为”不可回收“,这就是内存泄漏 。当然,被没有被标记为”不可回收“的对象(“垃圾”对象)所引用是不会阻止被引用对象被回收的,这种情况就不算是内存泄漏。
通常,导致无用的对象被GC Root无意引用的常见场景有以下几种:(注意这里只讨论”无意“的引用,开发者通过静态变量或生存期超长的对象建立的”有意“的引用不在讨论之列)
1)Event订阅
普通的事件订阅(event subscribing),例如代码source.SomeEvent += new SomeEventHandler(someObject.MyEventHandler),将创建一个从source到someObject的强引用(strong reference),如果source对象的生存期比someObject的长,那么将产生内存泄漏。
如一个在WPF/UWP中非常常见的场景:
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
Application.Current.MainWindow.SizeChanged += this.MainWindow_SizeChanged;
}
private void MainWindow_SizeChanged(object sender, SizeChangedEventArgs e)
{
Debug.WriteLine($"主窗体size改变:{e.NewSize}");
}
}
UserControl1订阅了MainWindow的SizeChanged事件,那么MainWindow将保持一个对UserControl1的引用。如果MainWindow的生存期比UserControl1长,那么将产生内存泄漏。
解决这类内存泄漏的方法有:
a)手动取消订阅(unsubscribe)
可以将上述代码修改如下:
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
this.Loaded += this.UserControl1_Loaded;
this.Unloaded += this.UserControl1_Unloaded;
}
private void UserControl1_Unloaded(object sender, RoutedEventArgs e)
{
Application.Current.MainWindow.SizeChanged -= this.MainWindow_SizeChanged;
}
private void UserControl1_Loaded(object sender, RoutedEventArgs e)
{
Application.Current.MainWindow.SizeChanged += this.MainWindow_SizeChanged;
}
private void MainWindow_SizeChanged(object sender, SizeChangedEventArgs e)
{
Debug.WriteLine($"主窗体size改变:{e.NewSize}");
}
}
由于Framework的Loaded和Unloaded事件都是成对出现,因此,可以保证当UserControl1被从Visual Tree卸载时,对MainWindow的SizeChanged被及时订阅,从而解除MainWindow对UserControl1的引用,避免内存泄漏。
b)弱事件模式(Weak Event Pattern):使用WeakReference或 WeakEventManager,或第三方的库(如Prism的EventAggregator)。这里只举一个WeakReference的例子,关于后者可以参考MSDN文档:https://docs.microsoft.com/en-us/dotnet/desktop/wpf/advanced/weak-event-patterns
还是上面的例子,用WeakReference改写后代码如下:
public class WeakEventHandler<TEventArgs> where TEventArgs : SizeChangedEventArgs
{
public WeakReference Reference { get; }
public MethodInfo Method { get; }
public WeakEventHandler(SizeChangedEventHandler eventHandler)
{
this.Handler = eventHandler;
this.Reference = new WeakReference(eventHandler.Target);
Method = eventHandler.Method;
}
public SizeChangedEventHandler Handler { get; }
public void Invoke(object sender, TEventArgs e)
{
object target = Reference.Target;
if (null != target)
{
Method.Invoke(target, new object[] { sender, e });
}
}
public static implicit operator SizeChangedEventHandler(WeakEventHandler<TEventArgs> weakHandler)
{
return weakHandler.Handler;
}
}
/// <summary>
/// Interaction logic for UserControl1.xaml
/// </summary>
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
Application.Current.MainWindow.SizeChanged += new WeakEventHandler<SizeChangedEventArgs>(this.MainWindow_SizeChanged);
}
private void MainWindow_SizeChanged(object sender, SizeChangedEventArgs e)
{
Debug.WriteLine($"主窗体size改变:{e.NewSize}");
}
}
c)尽可能利用匿名函数(anonymous method)并避免“捕获”对象的任何成员(member),如上面的例子可以改为:
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
Application.Current.MainWindow.SizeChanged += (s, e) =>
{
Debug.WriteLine($"主窗体size改变:{e.NewSize}");
};
}
}
2)在匿名函数中捕获对象的成员(member)
上面提到将event hander换成匿名函数并避免捕获对象的成员可以避免内存泄漏。换句话说,如果匿名函数捕获了对象的成员,就可能导致内存泄漏。如上面匿名函数的例子换成下面的:
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
Application.Current.MainWindow.SizeChanged += (s, e) =>
{
Debug.WriteLine($"{e.NewSize.Width - this.Width}");
};
}
}
这里,由于UserControl1的成员Width被匿名函数捕获,结果导致整个UserControl1的实例也被MainWindow所引用,从而产生内存泄漏。
这类泄漏的解决办法可能很简单——使用局部变量代替对象的成员:
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
var w = this.Width;
Application.Current.MainWindow.SizeChanged += (s, e) =>
{
Debug.WriteLine($"{e.NewSize.Width - w}");
};
}
}
3)不正确的Binding(WPF)
如果绑定的不是DependencyProperty而且没有实现INotifyPropertyChanged,那么将产生内存泄漏。这与WPF的Binding的实现机制有关:如果绑定的是DependencyProperty或一个实现了INotifyPropertyChanged的对象的属性,那么WPF将利用Weak events模式,不会产生内存泄漏。否则,WPF将不得不诉诸于订阅System.ComponentModel.PropertyDescriptor类的ValueChanged事件来监听绑定source的属性值的改变。问题在于,这将导致CLR创建一个从PropertyDescriptor到绑定source对象的一个强引用。多数情况下,CLR将用一个全局列表保存这个引用。这无疑将导致内存泄漏。
不过这种内存泄漏只有当BindingMode为OneWay或TwoWay时才会发生。当BindingMode为OneTime或OneWayToSource时,CLR不会创建强引用,即使Binding的不是DependencyProperty而且没有实现INotifyPropertyChanged。
与此类似的是绑定没有实现INotifyCollectionChanged接口的Collection,这是WPF将创建一个到这个Collection的强引用,产生内存泄漏。
4)WPF中x:Name导致的内存泄漏
如果Xaml的元素用x:Name进行了命名,那么WPF将创建一个到该元素的全局的强引用。例如:
<local:UserControl1 x:Name="MyUserControl1"/>
那么用code behind动态地将MyUserControl1从其父容器移除并不能真正导致该元素可以被回收,虽然看似MyUserControl1已经被移除了。
private void ButtonBase_OnClick(object sender, RoutedEventArgs e)
{
rootPanel.Children.Remove(this.MyUserControl1);
this.MyUserControl1 = null;
}
解决办法也很简单:
private void ButtonBase_OnClick(object sender, RoutedEventArgs e)
{
this.UnregisterName("MyUserControl1");
rootPanel.Children.Remove(this.MyUserControl1);
this.MyUserControl1 = null;
}
到目前为止,我们谈的sql语句都是托管内存(managed memory),这类内存是由GC管理的。非托管内存(unmanaged memory)则完全是另一回事事,下面简单讨论以下非托管内存泄漏。
2.非托管类内存泄漏(unmanaged memory leak)
下面通过一个简单的列子来说明这个问题:
public class SomeClass
{
private IntPtr _buffer;
public SomeClass()
{
_buffer = Marshal.AllocHGlobal(1000);
}
}
上面的对象在创建时通过Marshal.AllocHGlobal()分配了一块非托管内存。在底层,AllocHGlobal()调用了Win32的Kernel32.dll的LocalAlloc()函数。如果没有显式调用Marshal.FreeHGlobal()来释放这块内存,那么这块非托管类内存将被视为已占用,将长期停驻在堆内存,这正是典型的非托管类内存泄漏。
要解决这个问题,除了主动调用Marshal.FreeHGlobal(),还有一种简单直接的方法是在析构器里调用该方法,如:
public class SomeClass
{
private IntPtr _buffer;
public SomeClass()
{
_buffer = Marshal.AllocHGlobal(1000);
// do stuff without freeing the buffer memory
}
~SomeClass()
{
if (this._buffer != IntPtr.Zero)
{
Marshal.FreeHGlobal(_buffer);
_buffer = IntPtr.Zero;
}
}
}
在SomeClass被回收时,Destructor必然被调用(除非对这个对象调用了GC.SuppressFinalize),进而调用Marshal.FreeHGlobal(),这块非托管内存被回收,避免了内存泄漏。这意味着,只要没有托管类内存泄漏导致SomeClass无法被回收,这块非托管内存都能被回收。
在Constructor里分配非托管内存,在Destructor里释放, 这个解决方案似乎完美无缺。但是该方案的问题有二:首先,如果SomeClass因为托管类内存泄漏无法被回收,那么其非托管资源将无法被释放;其次,一个无用的托管对象何时被回收也就是说其Destructor什么时候被调用是不确定的,取决于GC。对于后一种情形的严重性,不妨考虑一个极端的例子:程序创建了大量小托管对象,而且这些对象都分配大量非托管内存。尽管没有托管类内存泄漏,这些小托管对象都可以回收,但是由于GC只能看到托管内存,看不到非托管内存,于是它认为不需要进行垃圾回收。情况严重时,将导致应用占用大量内存,其影响不亚于内存泄漏。
第二个问题的解决方案是实现Dispose模式,并在对象不再使用时尽早调用Dispose方法。
public class SomeClass : IDisposable
{
private IntPtr _buffer;
// To detect redundant calls
private bool _disposed = false;
public SomeClass()
{
_buffer = Marshal.AllocHGlobal(1000);
}
~SomeClass() => Dispose(false);
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
//加上这句后,则如果已经被disposed,则在回收时不需要调用析构器(调用析构器对性能有一定影响)
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (_disposed)
{
return;
}
if (disposing)
{
// TODO: dispose managed state (managed objects).
}
// TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
// TODO: set large fields to null.
if (this._buffer != IntPtr.Zero)
{
Marshal.FreeHGlobal(_buffer);
_buffer = IntPtr.Zero;
}
_disposed = true;
}
}
(上面的Dispose模式是MSDN和Resharper都推荐的模式,其中黑体字为新增代码)这意味着,当实现IDisposable接口的对象不再有用时,应该尽早调用其Dispose()方法。关于Dispose模式,这里有必要补充一点:在有些存在托管内存泄漏的情况下,我们不能被动依靠GC在销毁一个垃圾对象时调用它的析构器调用Dispose,因为由于托管内存泄漏,这个对象可能无法被GC回收。如下面的例子:
public class SomeClass : IDisposable
{
// To detect redundant calls
private bool _disposed = false;
public SomeClass()
{
Application.Current.Deactivated += this.Current_Deactivated;
}
private void Current_Deactivated(object sender, EventArgs e)
{
//do something
}
~SomeClass() => Dispose(false);
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Dispose(true);
//加上这句后,则如果已经被disposed,则在回收时不需要调用析构器(调用析构器对性能有一定影响)
GC.SuppressFinalize(this);
}
// Protected implementation of Dispose pattern.
protected virtual void Dispose(bool disposing)
{
if (_disposed)
{
return;
}
if (disposing)
{
// TODO: dispose managed state (managed objects).
Application.Current.Deactivated -= this.Current_Deactivated;
}
// TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
// TODO: set large fields to null.
_disposed = true;
}
}
由于被全局对象Application引用,在应用结束前这个对象都无法被回收的,因此其析构器也不会被调用。这时就c#教程
必须手动调用其Dispose()方法,否则将产生托管内存泄漏。
值得一提的是,上面的例子中,由于我们必须手动调用Dispose(),所以也就不再需要析构器里那些代码,也不需要判断_disposed是否为true。因此Dispose模式在这个例子中可以大大简化:
public class SomeClass : IDisposable
{
public SomeClass()
{
Application.Current.Deactivated += this.Current_Deactivated;
}
private void Current_Deactivated(object sender, EventArgs e)
{
//do something
}
// Public implementation of Dispose pattern callable by consumers.
public void Dispose()
{
Application.Current.Deactivated += this.Current_Deactivated;
}
}
总结:本文简单讨论了.NET/WPF中内存泄漏的类型,产生的原因,GC的工作原理,常见的内存泄漏场景以及相应的解决方案,正确的Dispose模式等。由于实际开发中内存泄漏问题的复杂性,本文未涉及的内存泄漏场景还有很多,如TextBox的Undo缓存泄漏、Attached Behaviors等。(原创文章,感谢阅读,欢迎批评指正,专注请注明出处)
参考文章:
http://dotnet.agilekiwi.com/blog/2010/04/memory-leaks-in-managed-code.html
https://michaelscodingspot.com/ways-to-cause-memory-leaks-in-dotnet
https://michaelscodingspot.com/find-fix-and-avoid-memory-leaks-in-c-net-8-best-practices/
https://stackoverflow.com/questions/18542940/can-bindings-create-memory-leaks-in-wpf/18543350#18543350
https://blog.jetbrains.com/dotnet/2014/09/04/fighting-common-wpf-memory-leaks-with-dotmemory/
https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose