Fuites mémoire en .NET : les causes qui tuent votre app (et comment les éviter)
Vous avez l'impression que votre appli rame de plus en plus en prod ? C'est peut-être une fuite mémoire.
Le garbage collector fait le gros du boulot, mais il ne peut pas tout gérer. Voici les causes que j'ai pu rencontrer sur des projets .NET.
1. Pas d'analyse mémoire pendant le développement
Sans profiler, vous ne verrez pas les fuites. Utilisez simplement le profiler mémoire de Visual Studio (menu Debug, Performance Profiler).
2. Fichiers et connexions non fermés (la classique)
Ouvrir un fichier ou une connexion DB sans les fermer = fuite garantie. Utilisez toujours using pour tout ce qui accède à des ressources externes.
Vécu : sur un projet, l'appli tombait pendant les pics de trafic. On check la base : plus de 1 000 connexions SQL ouvertes.
3. Cache qui grossit sans fin
Un cache sans limite de durée ou de taille = problème garanti. Ajoutez toujours un TimeToLive (MemoryCache.Set avec AbsoluteExpiration).
4. Events sans désabonnement
Un event crée une référence qui empêche la collecte de mémoire. N'oubliez jamais de faire event -= MonHandler quand vous n'en avez plus besoin.
5. Objets disposables mal gérés
Les objets qui utilisent des ressources natives (COM, handles, bitmaps...) échappent au GC. Implémentez IDisposable et appelez GC.SuppressFinalize(this) dans Dispose().
6. Variables statiques qui accumulent des données
Un static List<> qui se remplit = mémoire jamais libérée. Évitez de stocker de gros objets dans des variables statiques.
7. Objets qui se référencent en boucle
Un parent qui référence un enfant qui référence le parent = GC en PLS. Utilisez des références faibles (new WeakReference<MonType>(monObjet)).
8. Collections persistantes qui ne font que grandir
Les listes stockées dans des singletons ou services longue durée finissent par tout garder. Limitez la taille des collections ou videz-les périodiquement.
9. Opérations répétées sur des gros tableaux
Allouer un gros tableau à chaque appel = fatigue du GC. Utilisez ArrayPool<T> pour les réutiliser sans recréer.
À retenir : les fuites mémoire sont souvent invisibles jusqu'à ce que votre application ralentisse fortement ou plante en production. Gardez un œil sur la mémoire de vos apps : si elle monte sans jamais redescendre, c'est peut-être l'une de ces fuites.
Cet article est tiré d'une de mes publications LinkedIn : rejoignez la discussion ↗