https://www.jianshu.com/p/7e9ecb383bd0

我们经常会在程序中使用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方法中停止也是可以的。

作者：古意昌
链接：https://www.jianshu.com/p/7e9ecb383bd0#
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。