-4

我在一个使用PDFViewer 组件 和大 PDF(>85Kb,可能会影响 LOH)的应用程序上工作,并且在集成它后我的应用程序中遇到了内存泄漏的问题。

除其他外,我认为 LOH 碎片和 GC 弱引用。它没有效果:

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

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

通过我检测到的分析器、性能监视​​器和进程浏览器,在(创建新的 PDFViewer)/(删除旧的 PDFViewer)的每次迭代中,我们都会增加相同的页面文件、虚拟内存和工作集。LOH 的大小也没有增加,但第 2 代堆大小正在增加。

我没有机会吸引外部帮助,因为我的应用程序又硬又大,但现在我在 PDFViewer 应用程序中发现了同样的问题,您可以在上面的链接下载。当我主动调整窗口大小时,内存在增加。当我打开其他 pdf 或重新打开当前 pdf 时,尽管打开 pdf 调用处理旧 pdf,但内存不会收集:

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

也没有效果。

CLR拉了我的腿,我找了个理由摔断了整个头。

4

2 回答 2

0

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

于 2013-06-18T17:01:54.553 回答
0

拥有这条线_pdfDoc.Dispose();并不能保证这条线被调用。如果此行之前有任何错误或返回语句。不调用 dispose。将 _pdfDoc 放在一个using(...){ ... } 构造中将减少丢失端的变化。

衡量你的管理的方式不是那么可靠。您可以更好地使用内存分析器来查看长时间运行后内存中存在哪些对象。

于 2013-06-18T14:18:37.763 回答