众所周知，内存管理和如何避免内存泄漏（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; }
到目前为止，我们谈的都是托管内存（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引用，在应用结束前这个对象都无法被回收的，因此其析构器也不会被调用。这时就必须手动调用其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