我们经常会在程序中使用DispatcherTimer，但是如果一不小心就会发生内存泄漏，请看下面的Demo：
内存泄漏代码
我创建了一个简单的窗口Example1.xaml：
<Window x:Class="MemoryLeak.Example.Example1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</Window>
Example1.xaml.cs中的代码如下：
public partial class Example1 : Window
{
//这里产生一个大的内存占用，约50MB，用于在任务管理器看到这个窗口Show出来以后，进程内存占用剧增的现象
private readonly List<string> _bigList = ExampleHelper.BigList();
public Example1()
{
InitializeComponent();
DispatcherTimer timer = new DispatcherTimer { Interval = TimeSpan.FromSeconds(1) };
timer.Tick += Timer_Tick;
timer.Start();
}
private void Timer_Tick(object sender, EventArgs e)
{
Console.WriteLine(DateTime.Now);
}
}
内存泄漏现象
Example1 window = new Example1();
window.Show();
然后将此window直接关闭，那么显然这个window生命周期结束，再无引用。执行：
GC.Collect();
window占用的50MB内存应该被回收，然后在任务管理器中看此进程，其内存并没有被回收。什么东西阻止了我回收？阻止回收的根本原因是仍然有人引用！我们来挖一下，深层次的原因在哪里。
源码分析
timer生命周期分析
上面的代码非常的简单，就是在窗口构造函数执行的时候 new 了一个 DispatcherTimer，“老师”告诉我们，一个变量的生命周期在大括号内，也就是构造函数执行完毕之后timer就应该被回收了，但是事实上，窗口关闭以后，仍然每秒输出当前时间。到底发生了什么事呢？
我们去看看 DispatcherTimer 的源码发生了什么事：
public class DispatcherTimer
{
private Dispatcher _dispatcher;
public void Start()
{
//省略一些跟我们主题无关的源代码
this.Restart();
}
private void Restart()
{
//省略一些跟我们主题无关的源代码
this._dispatcher.AddTimer(this);
}
public void Stop()
{
//省略一些跟我们主题无关的源代码
this._dispatcher.RemoveTimer(this);
}
}
public class Dispatcher
{
public static Dispatcher CurrentDispatcher
{
get { return Dispatcher.FromThread(Thread.CurrentThread) ?? new Dispatcher(); }
}
private List<DispatcherTimer> _timers = new List<DispatcherTimer>();
internal void AddTimer(DispatcherTimer timer)
{
//省略一些跟我们主题无关的源代码
this._timers.Add(timer);
}
}
从源码中我们可以看到，DispatcherTimer的_dispatcher对象里面有一个_timers对象，timer.Start()调用的时候将timer实例加入了_timers列表中，造成了对timer对象的强引用。那问题来了，_dispatcher对象是哪里来的？DispatcherTimer的源码显示它看起来是一个实例变量，应该不会造成强引用呀。呵呵。
这个_dispatcher就是Dispatcher.CurrentDispatcher，Dispatcher. CurrentDispatcher是一个static的变量哦，什么是static？static对象就是生命周期跟进程的生命周期同样长的对象，所以如果你不调用timer.Stop()将timer从_timers中移除，你再也无法回收timer了，特别是window又关闭了，这个timer除了内部被引用外，外部再也没有办法通过正常的途径去找到它了，于是timer的内存泄漏产生。
window生命周期分析
虽然DispatcherTimer无法回收，但是我们本文的主题是想回收Example1这个window对象，真是坑啊，这么简单的代码有2个内存泄漏产生了。
言归正传，window.Show()完以后，点击window的关闭按钮，关闭了窗口。GC.Collect()并不能回收这个window占用的内存，那么一定有人引用了这个window，问题出现在哪里呢？
让我们仔细看看这句代码：timer.Tick += Timer_Tick;，这句代码的完整形式应该是timer.Tick += this.Timer_Tick;我们知道事件的工作原理是观察者模式，要实现观察者模式就必须有目标Target和处理函数Method，那么timer.Tick += Timer_Tick;这句话将this作为观察者模式中的Target，Timer_Tick作为Method，当事件发生的时候可以通过Target调用Target中的Method，所以timer.Tick += Timer_Tick;这句话就将window强引用了。
内存泄露原因深度剖析及解决措施
上述问题中谈到timer.Tick += Timer_Tick;，这句代码造成了对window的强引用，我们知道还有很多方式可以添加事件处理函数，比如匿名方法：
public Example1()
{
InitializeComponent();
DispatcherTimer timer = new DispatcherTimer { Interval = TimeSpan.FromSeconds(1) };
timer.Tick += (s, e) => { Console.WriteLine(DateTime.Now); };
timer.Start();
}
这个时候会不会造成window无法回收呢？答案是：window可以回收。
但如果是这样呢：timer.Tick += (s, e) => { Console.WriteLine(this.Width); };答案是：window无法回收。
timer不Stop()无法回收timer这一点我们已经很清楚了，但是匿名函数为什么有时会阻止window回收有时又不会阻止？
请看我的另一篇文章：《原来是这样：C#中的匿名函数 & 闭包（未完成）》
至此DispatcherTimer造成的内存泄漏分析完毕，我们知晓了微软是如何维护计时器的，也知道造成泄漏的根本原因就是还有引用，解决措施就很简单了：在不需要用到计时器的时候Stop就可以了，在Tick方法中停止也是可以的。
