Java Academy · Leçon

Détecter et corriger les fuites mémoire

Identifiez les modèles courants de fuite mémoire (collections statiques, écouteurs, caches) et corrigez-les.

Détecter et corriger les fuites mémoire est une leçon Java Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Java Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Java Academy comprend 4 leçons au total.

Qu’est-ce qu’une fuite mémoire en Java ?

Une fuite mémoire en Java se produit lorsque des objets ne sont plus nécessaires, mais restent fortement accessibles, ce qui empêche la collecte des déchets de les récupérer. Le tas continue de croître jusqu’à ce qu’une erreur OutOfMemoryError soit générée.

Accumulation dans une collection statique

Un champ statique contenant une collection qui grandit constitue une fuite classique. Les objets ajoutés mais jamais supprimés restent en vie pendant toute la durée de vie de l’application.

public class Cache {
    // LEAK: static list grows forever if items are never removed
    private static final List<Object> items = new ArrayList<>();
    public static void add(Object o) { items.add(o); }
    // Fix: add a remove() method or use a bounded cache
}

Écouteurs d’événements non désinscrits

Inscrire un écouteur sans jamais le supprimer maintient en vie l’écouteur ainsi que tous les objets auxquels il fait référence. Désinscrivez toujours les écouteurs lorsqu’ils ne sont plus nécessaires.

// Leak:
sensor.addListener(new DataLogger());
// Fix:
DataLogger logger = new DataLogger();
sensor.addListener(logger);
// ... when done:
sensor.removeListener(logger);

Variables ThreadLocal non nettoyées

Dans les pools de fils d’exécution, les valeurs de ThreadLocal persistent entre les tâches, car les fils sont réutilisés. Si elles ne sont pas supprimées, les données d’une tâche se propagent aux tâches suivantes exécutées sur le même fil.

private static final ThreadLocal<MyContext> CTX = new ThreadLocal<>();
// Always clean up after each task:
try {
    CTX.set(new MyContext(requestId));
    doWork();
} finally {
    CTX.remove(); // prevents leak in pooled threads
}

Fuites de chargeurs de classes dans les applications déployées à chaud

Dans les conteneurs de servlets, chaque déploiement utilise un nouveau chargeur de classes. Si une classe conserve une référence statique vers une classe de l’ancien chargeur, l’ancien chargeur de classes tout entier, ainsi que toutes ses classes, ne peut pas être récupéré par la collecte.

Détecter les fuites avec des instantanés du tas

Prenez un instantané du tas avec jmap -dump:format=b,file=heap.hprof <pid>, puis ouvrez-le dans Eclipse MAT ou VisualVM pour trouver les objets conservés les plus volumineux et leurs racines du ramasse-miettes.

// Take a heap dump:
jmap -dump:live,format=b,file=heap.hprof $(jps | grep MyApp | cut -d" " -f1)
// Or trigger on OOM:
// -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof

Analyseur de mémoire Eclipse (MAT)

Le rapport « Suspects de fuite » de MAT identifie automatiquement les objets dont la taille de tas conservée est importante et affiche le chemin depuis les racines du ramasse-miettes. Commencez par la vue « Arbre des dominants » pour trouver les principaux responsables.

Utiliser WeakReference pour éviter les fuites

Enveloppez les objets mis en cache ou les écouteurs dans WeakReference. Le ramasse-miettes peut les récupérer lorsque la mémoire est sous pression. Vérifiez toujours si le résultat de get() est nul.

Map<String, WeakReference<Image>> imageCache = new HashMap<>();
imageCache.put("logo", new WeakReference<>(loadImage("logo.png")));
Image logo = imageCache.get("logo") != null ? imageCache.get("logo").get() : null;
if (logo == null) logo = reload("logo.png"); // re-load if GCed

Caches bornés avec le LRU de LinkedHashMap

Surchargez removeEldestEntry dans une LinkedHashMap pour limiter la taille du cache et supprimer automatiquement l'entrée la moins récemment utilisée.

Map<String, String> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
    protected boolean removeEldestEntry(Map.Entry<String, String> e) {
        return size() > 100; // evict when over 100 entries
    }
};

Analyser les allocations avec Java Flight Recorder

JFR (Java Flight Recorder) capture les profils d'allocation avec une surcharge minimale. Activez-le avec -XX:StartFlightRecording et analysez les données avec JDK Mission Control.

// Start a 60-second JFR recording:
java -XX:StartFlightRecording=duration=60s,filename=rec.jfr MyApp
// Or via jcmd:
jcmd <pid> JFR.start duration=60s filename=rec.jfr

Corriger les fuites : liste de contrôle

Vérifiez les collections statiques, les écouteurs non désenregistrés, les ThreadLocals dans les pools, les fuites de connexions ou de flux (utilisez une gestion automatique des ressources), les références de classes internes vers des objets externes et les caches sans éviction.

Vérification rapide

Quel indicateur de JVM sauvegarde automatiquement le tas lorsqu'une OutOfMemoryError est levée ?

Bilan

Sources courantes de fuites Java : collections statiques, écouteurs non désenregistrés, ThreadLocals mis en pool et caches non bornés. Détectez-les avec des instantanés du tas et MAT. Corrigez-les avec des WeakReferences, des structures bornées et en supprimant toujours les références lorsqu'elles ne sont plus nécessaires.

Questions Fréquemment Posées

La leçon « Détecter et corriger les fuites mémoire » est-elle gratuite ?

Oui — le texte complet de « Détecter et corriger les fuites mémoire » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Java Academy, passe à CoddyKit PRO. Le cours Java Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Détecter et corriger les fuites mémoire » ?

Identifiez les modèles courants de fuite mémoire (collections statiques, écouteurs, caches) et corrigez-les. Tu pratiques Java Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Java Academy ?

Aucune expérience préalable n'est requise. Java Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Détecter et corriger les fuites mémoire » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Java Academy ?

Oui. Chaque leçon Java Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Régions du tas de la JVM et cycle de vie des objets
Algorithmes de GC : Serial, G1, ZGC, Shenandoah
Détecter et corriger les fuites mémoire
Options de réglage du GC et profilage avec JVisualVM

← Retour à Java Academy