13

情况

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

发现

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

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

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

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

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

问题

我们将不胜感激有关调试此类问题的任何建议。

WPF CommandManager 背景

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

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

4

2 回答 2

5

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

GC.GetTotalMemory(true);

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

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

关于调用 CanExecute 的问题，由于同样的性能问题，我尽量避免使用它们。相反，我在视图模型中使用属性并将 XAML 中可视元素的IsEnabled属性绑定到视图模型中的属性。通过这种方式，整体性能得到了提高，并且 CanExecute 调用消失了。

我希望这将有所帮助。

于 2012-11-29T12:53:44.303 回答
0

试试 CLRProfiler，这里是下载链接。它显示了分配、处置和存活的事件处理程序。我相信您可以通过使用此工具来追查根本原因。Advanced .NET Debugging 这本书列出了一些很好的调试工具，你可以阅读它以获得一些帮助。

于 2012-11-28T07:19:58.270 回答