内存泄漏之DispatcherTimer

们经常会在程序中使用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.CurrentDispatcherDispatcher. CurrentDispatcher是一个static的变量哦,什么是staticstatic对象就是生命周期跟进程的生命周期同样长的对象,所以如果你不调用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强引用了。

event.png

内存泄露原因深度剖析及解决措施

上述问题中谈到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无法回收。
timerStop()无法回收timer这一点我们已经很清楚了,但是匿名函数为什么有时会阻止window回收有时又不会阻止?
请看我的另一篇文章:《原来是这样:C#中的匿名函数 & 闭包(未完成)》

至此DispatcherTimer造成的内存泄漏分析完毕,我们知晓了微软是如何维护计时器的,也知道造成泄漏的根本原因就是还有引用,解决措施就很简单了:在不需要用到计时器的时候Stop就可以了,在Tick方法中停止也是可以的。



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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值