Corrección de fugas de memoria en IronPDF
Si está experimentando una aparente fuga de memoria en IronPDF, queremos saberlo. Nuestros ingenieros más veteranos se amontonarán ante una fuga de memoria para trabajar en una solución inmediata una vez identificada.
Así es como se informa de una fuga de memoria a support@ironsoftware.com :
1. Actualizar a la última versión de IronPdf
Si aún no lo está, actualice a la última versión de IronPdf.
2. Asegúrese de que ha desechado los objetos iDisposable
La gran mayoría de las fugas de memoria notificadas se deben a un uso incorrecto de la interfaz iDisposable de .NET.
Si cualquier clase .NET tiene un Dispose() probablemente sea iDisposable** y requerirá que el desarrollador se lo diga cuando haya terminado de utilizarlo..
Existe el malentendido común de que C# es un lenguaje "gestionado", que no requiere ninguna responsabilidad por parte del desarrollador para gestionar la memoria. Contrariamente a esta creencia, hay muchos objetos .NET comunes que los desarrolladores que no se dan cuenta no eliminan.
-Uso de objetos que implementan IDisposable
-Encontrar, corregir y evitar fugas de memoria en C# .NET: 8 prácticas recomendadas
No disponer manualmente de todas y cada una de las instancias de la clase iDisposable puede causar una fuga de memoria en tu código.
- System.IO.Stream - que es devuelto por la propiedad PdfDocument.Stream.
- System.Drawing.Image / System.Drawing.Bitmap - que devuelve el método PdfDocument.PageToBitmap.
- el propio IronPdf.PdfDocument -** también está marcado como iDisposable, ya que puede contener objetos no gestionados en nuestras versiones posteriores 2021 - 2024.
La solución más común
La mejor solución suele ser utilizar una **declaración using cuando se hace referencia a objetos iDisposable.
utilizando(var stream=myPdfDocument.Stream){// hacer cosas}
En C# 8 existe incluso una versión shorthand sin{} cierres
usando var stream=myPdfDocument.Stream;
3.Recoger la basura
El perfilador de memoria del depurador de Visual Studio puede subir y subir aunque no haya nada mal. Cuando se utiliza un sistema con mucha RAM, el tiempo de ejecución de .NET puede decidir que es más eficiente permitir que la basura permanezca en memoria hasta que la RAM del sistema esté casi llena o incluso utilizar un archivo de intercambio para guardarla.
Es posible instruir manualmente al recolector de basura .NET para deshacerse de sus objetos no utilizados en un punto seguro en-su ciclo de vida de la aplicación cuando:
- No renderizar un PDF
- Hay un objeto iDisposable abierto
Una forma de hacerlo es
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()Después de esto, el gráfico de uso de memoria debería caer a un nivel normal, pero no cero.
4. Si sigues teniendo una fuga de memoria, notifícalo.
Esto se respetará como una prioridad extremadamente alta
Por favor, lea esta guía, que instruye sobre cómo encontrar sus archivos de registro e informar de tal manera que no habrá necesidad de solicitar información adicional.
Esta lectura de 3 minutos nos ayudará a reproducir su problema con un 100% de precisión, para no hacerle perder el tiempo.
https://ironpdf.com/troubleshooting/engineering-request-pdf/
Gracias - A nadie le gustan las fugas de memoria, incluidos nosotros. Cuando se trabaja con objetos de "Bajo Nivel" o de Sistema como renderizado HTML, Interop, Gráficos y Streams sí son posibles. Así que vamos a arreglarlas!
IronPDF se ha convertido en lo que es gracias a los informes de errores y las peticiones de funciones de nuestros usuarios, así que gracias por su apoyo.
