Behebung von Speicherlecks in IronPDF
Wenn Sie ein offensichtliches Speicherleck in IronPDF haben, möchten wir es wissen. Unsere erfahrensten Techniker stürzen sich auf ein Speicherleck, um an einem Hotfix zu arbeiten, sobald es erkannt wurde.
So melden Sie ein Speicherleck an support@ironsoftware.com:
1. Update auf die neueste IronPDF-Version
Falls Sie dies noch nicht getan haben, aktualisieren Sie bitte auf die neueste IronPDF-Version.
2. Stellen Sie sicher, dass Sie Ihre iDisposable-Objekte entsorgt haben
Die überwiegende Mehrheit der gemeldeten Speicherlecks wird durch unsachgemäße Verwendung der .NET iDisposable-Schnittstelle verursacht.
Wenn eine .NET-Klasse über eine Dispose()-Methode verfügt – ist sie wahrscheinlich iDisposable _und der Entwickler muss ihr mitteilen, wann er sie nicht mehr verwendet.
Es ist ein weit verbreitetes Missverständnis, dass C# eine "verwaltete" Sprache ist, die keine Verantwortung des Entwicklers für die Speicherverwaltung erfordert. Entgegen dieser Annahme gibt es in der Tat viele gängige .NET-Objekte, die nicht realisierende Entwickler nicht entsorgen.
- Verwenden von Objekten, die IDisposable implementieren
Speicherlecks in C# .NET finden, beheben und vermeiden: 8 bewährte Praktiken
Wenn Sie nicht jede einzelne Instanz der Klasse iDisposable manuell entsorgen, kann dies zu einem Speicherverlust in Ihrem Code führen.
- System.IO.Stream - das von der PdfDocument.Stream-Eigenschaft zurückgegeben wird
- System.Drawing.Image / System.Drawing.Bitmap – das von der Methode PdfDocument.PageToBitmap zurückgegeben wird
- IronPdf.PdfDocument - selbst ist ebenfalls als iDisposable markiert, da es in unseren späteren Versionen von 2021 bis 2024 nicht verwaltete Objekte enthalten kann.
Die gebräuchlichste Lösung
Die beste Lösung besteht oft darin, eine using Anweisung zu verwenden, wenn man sich auf iDisposable Objekte bezieht.
using(var stream=myPdfDocument.Stream){// do stuff}
In C# 8 gibt es sogar eine Kurzform ohne {}-Abschlüsse
using var stream=myPdfDocument.Stream;
3.Müll sammeln
Der Speicher-Profiler des Visual Studio-Debuggers kann immer weiter ansteigen, auch wenn keine Fehler vorliegen. Bei der Verwendung eines Systems mit hohem Arbeitsspeicher kann die .NET-Laufzeitumgebung entscheiden, dass es effizienter ist, Müll im Speicher zu belassen, bis der Arbeitsspeicher des Systems fast voll ist, oder sogar eine Auslagerungsdatei zu verwenden.
Es ist möglich, den .NET Garbage Collector manuell anzuweisen, seine unbenutzten Objekte zu einem sicheren Zeitpunkt im Lebenszyklus Ihrer Anwendung zu entsorgen:
- PDF nicht wiedergeben
- Es ist ein iDisposable-Objekt geöffnet
Eine Möglichkeit, dies zu tun, ist
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()Danach sollte die Speichernutzungskurve auf ein normales, aber nicht auf ein Nullniveau fallen.
4. Wenn Sie immer noch ein Speicherleck haben - melden Sie es.
Diesem Anliegen wird höchste Priorität eingeräumt
Bitte lesen Sie diesen Leitfaden, in dem beschrieben wird, wie Sie Ihre Protokolldateien finden und so berichten können, dass Sie keine zusätzlichen Informationen anfordern müssen.
Diese 3 Minuten helfen uns, Ihr Problem mit 100%iger Genauigkeit zu reproduzieren, damit wir nicht Ihre Zeit verschwenden.
https://ironpdf.com/troubleshooting/engineering-request-pdf/
Danke - Niemand mag Speicherlecks, einschließlich uns. Bei der Arbeit mit "Low Level"- oder Systemobjekten wie HTML-Rendering, Interop, Grafik und Streams werden sie möglich. Also lass uns sie beheben!
IronPDF ist nur durch die Berücksichtigung der Fehlerberichte und Funktionswünsche unserer Benutzer zu dem geworden, was es heute ist, und wir danken Ihnen für Ihre Unterstützung.
