事件(Event)，绝大多数内存泄漏（Memory Leak）的元凶[上篇]

最近这两天一直在忙着为一个项目检查内存泄漏（Memory Leak）的问题，对相关的知识进行了一下简单的学习和探索，其间也有了一些粗浅的经验积累，今天特意写一篇相关的文章与大家分享。那些对内存泄漏稍微有点了解的人，对于本篇文章的标题，相信不会觉得是在危言耸听。就我查阅的资料，已经这两天的发现也证实了这一点：觉得部分的内存泄漏问题与事件（Event）有关。本篇文章将会介绍其原理，以及如何发现和解决由事件导致的内存泄漏问题。

为了让读者首先对这个主题有一个感官的印象，让大家觉得内存泄漏问题离我们并不遥远，我特意写了一个简单的应用程序。我们这个应用程序叫做TodoListManager，因为通过它可以实时查看属于用户的“待办事宜（Todolist）”。这是一个GUI的应用，有两个Windows Form组成：左侧的窗体是一个程序的主界面（为了简单起见，我甚至没有将其做成MDI窗体），点击Todo List菜单项，右面的Form被显示出来：所有的代码事宜将会全部列出，为了保证记录的实时显示，每隔5秒钟数据自动刷新一次。

首先定义表示每一项TotoList Item定义了一个相应的类型：Event（不是我们谈到的导致内存泄漏的事件）。Event仅仅包含简单的属性：主题（Subject），截至日期（DueDate）和相应的描述性文字（Description），Event定义如下：

using System;
namespace Artech.MemLeakByEvents
{
    public class Event
    {
        public string Subject { get; set; }
        public DateTime DueDate { get; set; }
        public string Description { get; set; }
        public Event(string subject, DateTime dueDate, string desc)
        {
            if (string.IsNullOrEmpty(subject))
            {
                throw new ArgumentNullException("subject");
            }
            this.Subject = subject;
            this.DueDate = dueDate;
            this.Description = desc ?? string.Empty;
        }
    }
}

然后我将所有逻辑（实际上仅仅是定期获取TodoList列表而已）定义在下面一个叫做TodoListManager的类型中。为了演示的需要，我特意将其定义成Singleton的形式，并采用System.Threading.Timer实现定时地获取Todo List的操作。

using System;
using System.Collections.Generic;
using System.Threading;
namespace Artech.MemLeakByEvents
{
    public  class TodoListManager
    {
        private static readonly TodoListManager instance = new TodoListManager();
        public event EventHandler<TodoListEventArgs> TodoListChanged;
        private Timer todoListRefreshSchedler;
        private TodoListManager()
        {
            todoListRefreshSchedler = new Timer
            (
                state =>
                {
                    if (null == TodoListChanged)
                    {
                        return;
                    }

                    TodoListChanged(null, new TodoListEventArgs(GetTodolist()));
                }
           , null, 0, 5000);
        }
        public static TodoListManager Instance
        {
            get
            {
                return instance;
            }
        }
        private List<Event> GetTodolist()
        {
            var list = new List<Event>();
            list.Add(new Event("Meeting with Testing Team", DateTime.Today.AddDays(2),"NIL"));
            list.Add(new Event("Deliver progress report to manager ", DateTime.Today.AddDays(7), "NIL"));
            return list;
        }
    }
}

对于Timer的每一个轮询，都会处触发一个类型为EventHandler<TodoListEventArgs>的事件，通过注册这个事件，可以通过类型为TodoListEventArgs的事件参数得到最新的TodoList的列表，TodoListEventArgs定义如下：

using System;
using System.Collections.Generic;
namespace Artech.MemLeakByEvents
{
    public class TodoListEventArgs : EventArgs
    {
        public IEnumerable<Event> TodoList
        { get; private set; }
        public TodoListEventArgs(IEnumerable<Event> todoList)
        {
            if (null == todoList)
            {
                throw new ArgumentNullException("todoList");
            }

            this.TodoList = todoList;
        }
    }
}

然后我们来看看我们的应用通过怎样的形式将每一个刷新的列表显示在TodolList窗体中。其实很简单，我仅仅是在窗体Load的时候注册TodoListManager的TodoListChanged事件，并将获取到的TodoList列表绑定到DataGridView上面。由于TodoListManager异步工作的原因，我借助了SynchronizationContext这么一个对象实现对数据的绑定。

using System;
using System.Threading;
using System.Windows.Forms;

namespace Artech.MemLeakByEvents
{
    public partial class TodoListForm : Form
    {
        public static SynchronizationContext SynchronizationContext
        { get; private set; }

        public TodoListForm()
        {
            InitializeComponent();
        }

        private void TodoListForm_Load(object sender, EventArgs e)
        {
            SynchronizationContext = SynchronizationContext.Current;
            TodoListManager.Instance.TodoListChanged += TodoListManager_TodoListChanged;
        }

        private void TodoListManager_TodoListChanged(object sender, TodoListEventArgs e)
        {
            SynchronizationContext.Post(
                state =>
                {
                    BindingSource bindingSource = new BindingSource();
                    bindingSource.DataSource = e.TodoList;
                    this.dataGridViewTodoList.DataSource = bindingSource;
                }, null);
        }
    }
}

整个应用就这么简单，但是为了确定是否真的出现内存泄漏，我们需要在查看内存状态的时候，确保GC把所有垃圾对象全部回收完毕。为此，我在整个应用级别定义了一个静态的System.Threading.Timer，让它每隔半秒调用一次GC.Collect()。

using System;
using System.Windows.Forms;
namespace Artech.MemLeakByEvents
{
    static class Program
    {
        static System.Threading.Timer gcScheduler = new System.Threading.Timer
            (state => GC.Collect(), null, 0, 500);
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new MainForm());
        }
    }
}

接下来我查看我们的应用程序是否会有内存泄漏的问题了。查看内存泄漏，当然不能通过我们的肉眼去捕捉，需要借助响应的Memory Profiling工具。我们有很多这样的工具，有免费的，也有需要付钱购买的。在这里我推荐两个Memory Profiling工具，一个是JetBrains的dotTrace，另一个是RedGate的ANTS Memory Profiler，前者是免费的，后者不是。在这里我通过后者来查看本应用的内存泄漏问题。

ANTS Memory Profiler通过这样的原理来确定你的应用程序是否有泄漏问题：如果你怀疑某个操作会导致应该被GC回收的对象没有被回收，那么你在之前对内存分配情况拍一张快照（Snapshot），然后执行该操作，在操作完成并确定GC完成相应的回收操作后，在拍一张快照。通过对比，找出多余的对象，并根据具体的情况分析该对象是否应该被GC回收，如果是的，怎意味着你的程序存在着内存泄漏问题。关于ANTS Memory Profiler的具体操作，这里就不再细说了，只要大家了解基本的原理，不影响对后面内容的理解就可以了。

通过ANTS Memory Profiler启动我们的应用程序后，在一开始的时候我们拍摄一张反映程序初始状态的内存快照，然后选择File\Todo List打开TodoListForm，等待一定的时间，再将TodoListForm关闭。为了让GC有充分的时间进行垃圾回收，不妨再作相应的等待，然后拍下第二张快照。在Class List视图中，你会发现原本应该被垃圾回收的TodoListForm窗体对象还存在于内存之中。

那么是什么导致TodoListForm不能GC正常回收呢？熟悉GC原理的人应该知道，原因只有一个，那就是被某些正在使用或者会被使用，或者GC认为正在正在使用或者会被使用的对象引用着（Jeffrey Richiter将这些对象成为所谓的根）。ANTS Memory Profiler的强大之处就是可以让你可以很清楚地看到这个对象正在被那些其他的对象引用着。

左图就是TodoListForm对象在内存中的引用链，我们可以很清楚地看到：该对象被TodoListManager的一个类型为EventHandler<TodoListEventArgs>的事件引用，这个对象实际上是一个Delegate对象，而TodoListForm作为这个Delegate对象的Target。通过上面给出的代码，我们不难想出是由于在TodoListForm实现了对TodoListManager的TotoListChanged事件注册导致了TodoListManager不能被垃圾回收。

上面的实力说明了这么一种情况：对于GUI应用可视化树形结构来说，一个窗体被关闭，照例说它应该成为垃圾对象，GC在执行垃圾回收的时候就可以将其清楚的。但是，由于该对象注册了一个事件到一个生命周期很长的对象（在本例中，TodoManager是一个Singletone对象，具有和整个应用程序一样的生命周期），它就是被这么一个对象长期引用，进而阻止 GC对其的回收工作。

所以，在这种情况：短暂生命周期注册事件到长期生命周期对象上，在该对象被Dispose的时候，应该解除事件的注册。你可以通过实现System.IDisposable接口，将解除事件注册的操作放在Dispose方法中。对于本里来说，你可以将相应的操作注册到Form的Closing、Closed或者Disposed事件中。比如在下面代码中，我为TodoListForm添加了如下一个Closing事件处理程序：

using System;
using System.Threading;
using System.Windows.Forms;

namespace Artech.MemLeakByEvents
{
    public partial class TodoListForm : Form
    {
        //省略其他成员
        private void TodoListManager_TodoListChanged(object sender, TodoListEventArgs e)
        {
            SynchronizationContext.Post(
                state =>
                {
                    BindingSource bindingSource = new BindingSource();
                    bindingSource.DataSource = e.TodoList;
                    this.dataGridViewTodoList.DataSource = bindingSource;
                }, null);
        }

        private void TodoListForm_FormClosing(object sender, FormClosingEventArgs e)
        {
            TodoListManager.Instance.TodoListChanged -= TodoListManager_TodoListChanged;
        }
    }
}

那么，在此按照上面的流程利用ANTS Memory Profiler查看内存泄漏，在第二个快照中，你将再也看不到TodoListForm的身影（如下图）。本篇主要介绍如何重现事件注册导致内存泄露，已及最直接的解决方案。下一篇我将进一步对其背后的原理进行剖析，并提出另一种更加“优雅而可靠”解决方案。

作者：Artech
出处：http://artech.cnblogs.com/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。