.net - 为什么从不调用 NET 垃圾收集器？

Question

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

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

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

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

因此我调查了终结器线程中死锁的方向
(参见 http://dotnetdebug.net/2005/06/22/blocked-finalizer-thread/)
但找不到死锁的迹象。此外，与死锁理论相反的是，在使用内存分析器进行内存快照后，触发 GC.Collect()， View 被垃圾收集 - 分别执行它们的终结器并且一切正常。

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

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

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

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

此致

和我

Answer 1

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

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

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