使用Visual Studio 2017诊断工具排查WPF应用内存泄漏问题

我平时排查WPF窗口内存泄漏时，都是这么一步步深挖的，你可以照着试试：

第一步：查看窗口实例的保留引用链 #

当你在托管内存快照里找到那个本该被回收的窗口实例后，右键它，选择**“显示保留的对象”**（VS2017里对应的选项是“查看引用路径”）。这个操作会展示出所有阻止GC回收这个窗口的引用链——这就是泄漏的核心线索。

第二步：顺着引用链排查常见泄漏源头 #

顺着引用链往上梳理，重点关注以下几类“不该存在”的引用：

• 静态对象/单例的引用：如果引用链里出现了静态类、单例服务或者全局事件（比如Application.Current的事件），大概率是窗口订阅了这些对象的事件但没取消，或者被静态集合持有没移除。
• 未清理的事件订阅：比如窗口订阅了ViewModel的PropertyChanged事件，但ViewModel因为被其他长生命周期对象引用而存活，反过来把窗口“拽”在内存里。
• 绑定相关的残留引用：比如窗口的DataContext绑定到了单例ViewModel，或者使用OneWayToSource绑定后没正确解绑；自定义DependencyProperty处理不当也可能导致引用残留。
• 未停止的后台任务/定时器：窗口里的DispatcherTimer、Timer或者后台Task，如果没在窗口关闭时停止并置为null，会一直持有窗口的引用。
• 线程上下文引用：后台线程如果捕获了窗口的同步上下文（比如用Dispatcher.Invoke），或者线程本身还在运行且持有窗口引用，也会导致泄漏。

第三步：针对性验证和修复 #

找到可疑引用后，你可以通过这些操作验证并修复：

1. 手动触发GC排除延迟回收：在窗口关闭后执行这段代码，再拍快照确认：

   GC.Collect();
   GC.WaitForPendingFinalizers();
   GC.Collect();
   

2. 清理事件订阅：在窗口的Closed事件里取消所有订阅：

   private void Window_Closed(object sender, EventArgs e)
   {
       // 取消ViewModel的事件订阅
       (DataContext as MyViewModel)?.PropertyChanged -= ViewModel_PropertyChanged;
       // 取消全局事件订阅
       Application.Current.Exit -= Application_Exit;
   }
   

3. 置空长生命周期引用：比如清空DataContext或者移除静态集合里的窗口引用：

   private void Window_Closed(object sender, EventArgs e)
   {
       DataContext = null;
       // 如果窗口被加入过静态集合
       MyStaticClass.WindowCollection.Remove(this);
   }
   

4. 停止后台任务：关闭定时器或取消后台任务的令牌：

   private void Window_Closed(object sender, EventArgs e)
   {
       _dispatcherTimer?.Stop();
       _dispatcherTimer = null;
       _cancellationTokenSource?.Cancel();
   }
   

实用小技巧 #

• 在内存快照里用筛选器搜索EventRegistration或者你的窗口类名，快速定位未取消的事件注册。
• 对比两次快照：第一次是打开窗口后，第二次是关闭窗口并触发GC后，查看窗口实例数量变化，确认泄漏是否真的存在。
• 如果引用链里出现WeakReference相关对象，检查是不是你用了弱引用但不小心被强引用覆盖了。

内容的提问来源于stack exchange，提问作者user1515791