c# - WPF GarbageCollection 中的高级调试建议

Question

情况

我们正在运行一个大型 WPF 应用程序，该应用程序在相当长的一段时间内不会释放内存。这不是真正的内存泄漏，因为内存最终会被释放。我知道通常情况下，这不会被视为问题。不幸的是，它与 WPF 命令基础结构一起成为性能问题。有关更详细的说明，请参见下文。

调查结果

我们有执行典型用例的自动化测试。有些情况下工作正常并及时释放内存。其他人则占用内存，直到客户端最小化、打开新窗口或发生触发 Gen2 收集的其他一些情况。

• 通过 ANTS，我们看到对象没有 GC Root，但有很多对其他需要终结的对象的引用。

• WinDbg 不显示任何准备好完成的对象。

• 运行多个 GC.Collect()，GC.WaitForPendingFinalizers() 完全释放内存。

• 我们知道哪个 UI 操作会导致高内存情况，但我们无法识别任何可疑代码。

问题

对于调试此类问题的任何建议，我们将不胜感激。

---

WPF CommandManager 背景

WPF CommandManager 拥有用于引发 CanExecuteChanged 事件的 WeakReferences (_requerySuggestedHandlers) 的私有(private)集合。处理 CanExecuteChanged 的成本很高(尤其是为 CanExecute 寻找 EventRoute，这显然是一个 RoutedEvent)。每当 CommandManager 想要重新查询命令是否可以执行时，它都会遍历此集合并调用相应命令源上的 CanExecuteChanged 事件。

只要引用对象有 GC 句柄，WeakReferences 就不会从该集合中删除。虽然尚未收集对象，但 CommandHelper 会继续处理这些元素(ButtonBase 或 MenuItems)的 CanExecute 事件。如果有大量垃圾(如我们的情况)，这可能会导致调用 CanExecute 事件处理程序的次数非常多，从而导致应用程序非常缓慢。

Answer 1

我的一个应用程序也有同样的问题。在每次打开窗口时，我都会调用:

GC.GetTotalMemory(true);

这会强制GC立即清理内存，无需等待。您可以在此处阅读有关此方法的更多信息:

http://msdn.microsoft.com/en-us/library/system.gc.gettotalmemory.aspx

关于调用 CanExecute 的问题，由于同样的性能问题，我尽量避免调用它们。相反，我在我的 View 模型中使用属性并将 XAML 中可视元素的 IsEnabled 属性绑定(bind)到 View 模型中的属性。这样，整体性能得到提升，CanExecute 调用消失了。

希望对您有所帮助。