对象卡在 WPF 应用程序的第 2 代答案

【问题标题】：Object stuck in Generation 2 of WPF app对象卡在 WPF 应用程序的第 2 代
【发布时间】：2016-01-10 18:10:54
【问题描述】：

我有一个 WPF/E 应用程序，它遇到了巨大的性能问题以及内存泄漏。

使用 red gate 的 .NET 内存分析器确实有帮助，但我担心的是对象（使用 10 分钟后>100MB）一直停留在第 2 代 GC。

这会导致应用程序显着变慢时出现性能问题。调用 GC.Collect() 确实回收了一些内存，但这不是解决方案，因为不建议调用 GC - 而且我也不希望对象移动到第 2 代。

在 WPF MVVM 模式（或其他模式）中是否有任何最佳实践可以遵循，以使到达第 2 代的对象保持在最低限度？提前致谢！

【问题讨论】：

GC 无法收集“活动”实例，因为您的实例仍被其他一些对象保留。您需要通过内存分析器检查代码中的可疑区域来找出答案。有一些替代方案，例如WeakReference 以确保可以收集您的对象，但我不确定它是否适合您的情况，因为没有提供信息。底线是长生命周期的实例应该留在 Gen2 中并留在那里。这没什么不好。唯一的问题是您需要在 Gen2 到达那里后立即释放这些内存。不要混淆问题。
内存泄漏是另一个没有多少人能提供帮助的问题。好吧...除非您可以缩小您怀疑导致内存泄漏的特定类或代码段并将代码发布到问题...
@cscmh99 我明白了。您能否详细说明一下唯一的问题是您需要在 Gen2 中释放这些内存后不久。我还将深入研究代码并对此进行进一步调查。
请参阅msdn.microsoft.com/en-us/library/ms973837.aspx 的“Too Many Near-Long-Life Objects”部分。同样，在 Gen2 中拥有长寿命的内存根本不是问题。拥有“几乎长寿”的对象是问题所在。因此，如果“几乎长生”对象不是您的情况，请不要担心 Gen2 中的对象

【解决方案1】：

在 WPF MVVM 模式中是否有可遵循的最佳实践（或否则）以使到达第 2 代的对象保持在最低限度？

除了一般的最佳实践（例如处置所有 IDisposable 实例和取消订阅长期偶数订阅）之外，对于 MVVM 没有什么特别之处。

在这种情况下手动调用 GC.Collect 是没有意义的。如果您的对象在 Gen2 中，则意味着它们已经经历了两个垃圾周期。因此，有一些对这些实例的引用。

我想你应该做的是再看看这些实例，看看你是否有任何实时事件订阅，如果有，请取消订阅它们。并检查是否有任何未处理的 IDisposable 字段。如果有任何 IDisposable 字段最好implement IDisposable Pattern。

【讨论】：