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 ein Dispose() methode - sie ist wahrscheinlich iDisposable** __und verlangt vom Entwickler, dass er ihr mitteilt, wann er sie nicht mehr verwenden möchte
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.
- Verwendung von Objekten, die IDisposable implementieren
Finden, Beheben und Vermeiden von Speicherlecks in C# .NET: 8 Best Practices
Wenn Sie nicht jede einzelne Instanz der Klasse iDisposable manuell entsorgen, kann dies zu einem Speicherverlust in Ihrem Code führen.
- System.IO.Stream - der von der Eigenschaft PdfDocument.Stream 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 2021 - 2024 nicht verwaltete Objekte enthalten kann.
Die häufigste Lösung
Die beste Lösung ist oft die Verwendung einer using Statement, wenn man sich auf iDisposable Objekte bezieht.
verwendung(var stream=myPdfDocument.Stream){// Dinge tun}`
In C# 8 gibt es sogar eine Kurzschrift-Version ohne{} verschlü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, auch wir nicht. Bei der Arbeit mit "Low Level"- oder Systemobjekten wie HTML-Rendering, Interop, Grafik und Streams werden sie möglich. Reparieren wir sie also!
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.
