Question

我参与了使用PDFViewer component的应用程序和大的PDF（> 85Kb，这可能会对LOH产生影响），并且在我集成它之后，我在应用程序中遇到了memoryleak的问题。

除其他外，我认为LOH碎片和GC弱参考。它没有效果：

GC.Collect();
GC.WaitForFullGCComplete();
GC.Collect();
GC.WaitForFullGCComplete();

尽管它应该收集第2代的堆。

通过我检测到的分析器，perfmon和进程探索器，在每次迭代（创建新的PDFViewer）/（删除旧的PDFViewer）中，我们都有相同的页面文件，虚拟内存和工作集。 LOH的大小也没有增加，但第2代堆大小正在增加。

我没有机会吸引外部帮助因为我的应用程序很难而且很大，但现在我在PDFViewer应用程序中检测到同样的问题，您可以在上面的链接下载。当我主动调整窗口大小时，内存会增加。当我打开其他pdf或重新打开当前的pdf时，尽管打开pdf calles处理旧的pdf，但内存仍未收集：

_pdfDoc.Dispose();
_pdfDoc = null;
GC.Collect()

也没有效果。

CLR拉了我的腿，为了找到理由，我整理了一下。

Answer 1

通过让行_pdfDoc.Dispose();无法保证该行被调用。如果此行之前有任何错误或return语句。处置不被调用。将_pdfDoc置于using(...){ ... }构造中将减少损失的变化。

你的管理层不太可靠的方式。在长时间运行之后，您可以更好地使用内存分析器查看内存中的对象。

Answer 2

如果它是一个查看器应用程序，它应该将PDF命令转换为光栅表示。大多数可能使用Image类作为画布。当你谈到主动调整大小和内存使用量增加时，我会考虑未配置的位图或其他GDI资源。看看那个代码。