深入理解.NET/WPF内存泄漏

最新推荐文章于 2024-09-26 07:45:50 发布

Unknowncheats

最新推荐文章于 2024-09-26 07:45:50 发布

阅读量1.3k

点赞数 1

分类专栏：技术

原文链接：https://www.colorgg.com

版权

技术专栏收录该内容

559 篇文章 8 订阅

订阅专栏

众所周知，内存管理和如何避免内存泄漏（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