情况
我们正在运行一个大型 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 事件处理程序的次数非常多,从而导致应用程序非常缓慢。
最佳答案
我的一个应用程序也有同样的问题。在每次打开窗口时,我都会调用:
GC.GetTotalMemory(true);
这会强制GC立即清理内存,无需等待。您可以在此处阅读有关此方法的更多信息:
http://msdn.microsoft.com/en-us/library/system.gc.gettotalmemory.aspx
关于调用 CanExecute 的问题,由于同样的性能问题,我尽量避免调用它们。相反,我在我的 View 模型中使用属性并将 XAML 中可视元素的 IsEnabled 属性绑定(bind)到 View 模型中的属性。这样,整体性能得到提升,CanExecute 调用消失了。
希望对您有所帮助。
关于c# - WPF GarbageCollection 中的高级调试建议,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13568120/