4

我正在开发一个内存消耗存在问题的应用程序。如果用户在应用程序中单击的时间足够长，则会以 OutOfMemoryException 结束。

我用“ANTS Memory Profiler”对应用程序进行了很长时间的分析，我认为没有“经典”内存泄漏（例如，防止对象被垃圾收集的事件处理程序）。

但是所有保留在内存中的对象都有一个共同点——它们直接或间接地使用实现终结器的标准.NET 控件（例如TextBox、Numberbox）。在“ANTS Memory Profiler Instance Retention Graph”中，我可以看到唯一持有控件引用的实例是 .NET Finalizer Queue。

链接保留图（我没有足够的声誉直接发布图像:-)）--> http://i50.tinypic.com/2d6r6nn.png

因此，我调查了终结器线程中死锁的方向（参见http://dotnetdebug.ne ​​t/2005/06/22/blocked-finalizer-thread/ ），但找不到死锁的迹象。此外，反对死锁理论的是，在触发 GC.Collect() 的内存分析器的内存快照之后，视图被垃圾收集 - 分别执行它们的终结器并且一切都很好。

所以，这看起来像是带有 Finalizer 的 .net 对象的正常生命周期，对吧？但是在我的应用程序中，我可以单击直到出现 OutOfMemoryException 并且垃圾收集器永远不会运行！

处理该问题的最后一次尝试是使用 GC.AddMemoryPressure()，因为在视图中有很多位图，它们分配了很多非托管代码。但这也不能促使垃圾收集器收集空闲内存。

所以，我认为应用程序中的一个概念本质上是错误的，它阻止了 GC 释放内存，但我完全不知道是什么。

有没有人经历过类似的经历并有任何线索？

此致

和我

4

3 回答 3

3

OutOfMemoryException有时会说谎。有时它意味着“我无法获得非托管句柄” - 它并不总是与内存相关。问题是通常很难说出为什么会失败，“内存不足”可能是一个合理的猜测。

好像很多事情都没有及时处理。处理它们会调用它们的自定义代码，以急切地主动释放它们未损坏的句柄。

相反，GC主要是由内存压力触发的。如今，PC 可以有大量内存，但会用完非托管句柄。

于 2013-03-11T15:55:46.193 回答
0

在MODEL-VIEW-VIEWMODEL (MVVM)中，如果您使用特殊的第三方引用，则可以将对象清除为显式控件。也许你只需要包括 object.Dispose和object = null

何时在 MVVM Light 中处理 ViewModel

于 2013-03-11T16:04:29.913 回答
0

可能有很多东西

这只是一个让我记忆犹新的怪事

在集合中检查 = 值，如果是则返回。

查找对 NotifyPropertyChanged 的​​不必要调用。
我有一个案例，我正在通过公共属性加载 ObservableCollection，它正在排队多个 NotifyPropertyChanged，这导致内存不足。
然后我加载了私有变量，完成后只调用了一次 NotifyPropertyChanged，它修复了内存不足的问题。

于 2013-03-11T16:09:44.730 回答