Fuite de mémoire dans IronPDF
Si vous constatez une fuite de mémoire apparente dans IronPDF, nous voulons le savoir. Nos ingénieurs les plus chevronnés s'empareront d'une fuite de mémoire pour travailler sur une solution rapide une fois qu'elle aura été identifiée.
Voici comment signaler une fuite de mémoire à support@ironsoftware.com :
1. Mise à jour vers la dernière version d'IronPDF
Si ce n'est pas déjà fait, veuillez mettre à jour la dernière version d'IronPDF.
2. Assurez-vous d'avoir éliminé vos objets iDisposables
La grande majorité des fuites de mémoire signalées sont dues à une mauvaise utilisation de l'interface iDisposable de .NET.
si une classe .NET possède une fonction Dispose() il est probablement iDisposable** __et demandera au développeur de lui indiquer quand il a fini de l'utiliser
Il existe un malentendu courant selon lequel C# est un langage "géré", ne nécessitant aucune responsabilité de la part du développeur pour la gestion de la mémoire. Contrairement à cette croyance, il existe en fait de nombreux objets .NET courants que les développeurs non avertis ne parviennent pas à éliminer.
- Utilisation d'objets qui implémentent IDisposable
Trouver, réparer et éviter les fuites de mémoire en C# .NET : 8 meilleures pratiques
Le fait de ne pas éliminer manuellement chaque instance de la classe iDisposable peut entraîner une fuite de mémoire dans votre code.
- System.IO.Stream - qui est renvoyé par la propriété PdfDocument.Stream
- System.Drawing.Image / System.Drawing.Bitmap - qui est retourné par la méthode PdfDocument.PageToBitmap
- IronPdf.PdfDocument - lui-même est marqué iDisposable, car il peut contenir des objets non gérés dans nos versions ultérieures 2021 - 2024.
La solution la plus courante
La meilleure solution est souvent d'utiliser une déclaration using lorsqu'on se réfère à des objets iDisposable.
utilisation(var stream=myPdfDocument.Stream){// faire des choses}
En C# 8, il existe même une version sortante sans {} fermetures
utilisant var stream=myPdfDocument.Stream;
3.Collecte des ordures
Le profileur de mémoire du débogueur Visual Studio peut augmenter sans cesse, même si tout va bien. Lorsque vous utilisez un système à mémoire vive élevée, le moteur d'exécution .NET peut décider qu'il est plus efficace de laisser les déchets en mémoire jusqu'à ce que la mémoire vive du système soit presque pleine ou même d'utiliser un fichier d'échange pour les conserver.
Il est possible d'ordonner manuellement au ramasse-miettes .NET de se débarrasser de ses objets inutilisés à un moment sûr du cycle de vie de votre application :
- Pas de rendu d'un PDF
- Un objet iDisposable est ouvert
Une façon de procéder consiste à
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()Ensuite, le graphique d'utilisation de la mémoire devrait redescendre à un niveau normal, mais non nul.
4. Si vous avez encore une fuite de mémoire, signalez-la.
Cet objectif sera considéré comme une priorité absolue
Veuillez lire ce guide, qui vous indique comment trouver vos fichiers journaux et les rapporter de manière à ce qu'il ne soit pas nécessaire de demander des informations supplémentaires.
Cette lecture de 3 minutes nous aidera à reproduire votre problème avec une précision de 100 %, afin que nous ne perdions pas votre temps.
https://ironpdf.com/troubleshooting/engineering-request-pdf/
Merci - Personne n'aime les fuites de mémoire, y compris nous. Lorsque l'on travaille avec des objets de "bas niveau" ou des objets système tels que le rendu HTML, l'interopérabilité, les graphiques et les flux, ces objets deviennent possibles. Alors, corrigeons-les!
IronPDF n'est devenu ce qu'il est aujourd'hui qu'en écoutant les rapports de bogues et les demandes de fonctionnalités de nos utilisateurs, alors merci pour votre soutien.
