IronPDF 中的記憶體洩漏

This article was translated from English: Does it need improvement?
Translated
View the article in English

如果您在使用 IronPDF 時遇到明顯的記憶體洩漏問題,我們希望了解此情況。一旦確定問題,我們最資深的工程師將立即集中力量p來修復此記憶體洩漏。

以下是如何向 support@ironsoftware.com 報告記憶體洩漏:

1. 更新到最新的 IronPdf 版本

如果您還沒有,請更新到最新的 IronPdf 版本。

2. 確保已處理您的 iDisposable 物件

大多數報告的記憶體洩漏問題是由於不正確使用 .NET 的 iDisposable 介面所引起的。

_如果任何 .NET 類別有一個 Dispose() 方法 - 它可能是 iDisposable**,并且需要開發人員在使用完它後告知。

有一個普遍的誤解認為 C# 是一種“託管”語言,不需要開發人員負責管理記憶體。與這種信念相反,實際上有許多常見的 .NET 對象,未意識到的開發人員未能處理。 使用實現IDisposable的對象

未能手動釋放每個 iDisposable 類實例可能會導致程式碼中的記憶體洩漏。

  • System.IO.Stream - 由 PdfDocument.Stream 屬性返回
  • System.Drawing.Image / System.Drawing.Bitmap - 由 PdfDocument.PageToBitmap 方法返回

  • IronPdf.PdfDocument - 自身也被標記為 iDisposable,因為在我們 2021 - 2024 的後續版本中它可能包含非托管物件。

最常見的解決方案

最佳解決方案通常是在引用 iDisposable 對象時使用 using 語句。

(var stream=我的PdfDocument.Stream){// 執行操作}在 C# 8 中,甚至還有一個 簡寫 版本沒有 {} 閉包

using var stream=myPdfDocument.Stream;

3.收集垃圾

Visual Studio 的調試器內存分析器可能會不斷增加,即使沒有任何問題。當使用高 RAM 系統時,.NET 運行時可能會認為允許垃圾留在內存中直到系統 RAM 幾乎滿或甚至使用交換文件來保持是更有效的。

可以在應用程序生命週期的安全點手動指示 .NET 垃圾收集器處理未使用的對象,當:

  • 不渲染 PDF 時
  • 有 iDisposable 對象開啟時

一種方法是這樣做

System.GC.Collect();
System.GC.WaitForPendingFinalizers();
System.GC.Collect();
System.GC.Collect();
System.GC.WaitForPendingFinalizers();
System.GC.Collect();
System.GC.Collect()
System.GC.WaitForPendingFinalizers()
System.GC.Collect()
VB   C#

之後,記憶體使用情況圖表應該會下降到正常但非零的水平。

4. 如果您仍有內存洩漏 - 請回報。這將被視為極高的優先級

請閱讀本指南,其中說明了如何找到您的日誌文件並以這種方式報告,這樣就不需要額外的信息請求。

這篇需要 3 分鐘閱讀的文章將幫助我們 100% 準確地重現您的問題,這樣我們不會浪費您的時間。

https://ironpdf.com/troubleshooting/engineering-request-pdf/

謝謝 - 沒有人喜歡記憶體洩漏,包括我們在內。當使用像HTML渲染、Interop、Graphics和Streams等“低級”或系統對象時,它們確實有可能發生。所以讓我們來修復它們。!

IronPDF 能成為今天的樣子,全靠我們傾聽用戶的錯誤報告和功能請求,所以感謝您的支持。