Mémoire et ramasse-miettes en Java : ce qui se passe vraiment sous le capot

Comment Java gère la mémoire : pas seulement le « ramasse-miettes »

De nombreux développeurs qui passent à Java depuis C++ ou Python se réjouissent d'abord : « Youpi, plus besoin de penser aux fuites mémoire ! ». Puis ils reçoivent une OutOfMemoryError au pire moment et comprennent que la gestion de la mémoire en Java nécessite une compréhension approfondie. Aujourd'hui, nous allons jeter un coup d'œil sous le capot de la JVM et analyser comment fonctionnent réellement la mémoire et le ramasse-miettes en Java.

Cet article sera utile aussi bien aux débutants qui souhaitent comprendre le Java memory model qu'aux développeurs expérimentés qui cherchent des moyens d'optimiser le garbage collection Java. C'est parti !

Comment la mémoire est organisée en Java : le tas, la pile et Metaspace

Avant de parler du ramasse-miettes Java, il faut comprendre où « vivent » exactement vos objets. La JVM divise la mémoire en plusieurs zones clés :

\n
• Heap (tas) — ici sont stockés tous les objets créés. C'est le principal champ d'action du garbage collection Java.
\n
• Stack (pile) — stocke les types primitifs et les références vers les objets dans le tas. Chaque thread a sa propre pile.
\n
• Metaspace — a remplacé PermGen dans Java 8, stocke les métadonnées des classes.
\n
• Code Cache — code compilé par le compilateur JIT.
\n

Voici un exemple simple montrant où les données aboutissent :

public class MemoryDemo {\n    public static void main(String[] args) {\n        int number = 42;                    // Type primitif — dans la pile\n        String text = "Hello";              // Référence dans la pile, objet dans le tas\n        List<String> list = new ArrayList<>(); // Référence dans la pile, liste dans le tas\n        list.add("Java");                   // La chaîne "Java" — aussi dans le tas\n    }\n}\n

Point clé : tous les objets créés via new aboutissent dans le heap Java. C'est cette zone que « surveille » le ramasse-miettes en Java.

Pourquoi le ramasse-miettes n'est pas un ennemi mais un ami (si on comprend sa logique)

De nombreux développeurs craignent le Java GC à cause des pauses « Stop-The-World ». Mais regardons la vérité en face : sans la gestion automatique de la mémoire Java, nous écririons manuellement free() et attraperions des segfaults. Le ramasse-miettes Java n'est pas un démon maléfique, mais un mécanisme complexe et intelligent.

Principes de base du fonctionnement du garbage collection Java :

\n
• Un objet est considéré comme « déchet » s'il n'y a pas de références actives depuis la pile ou les champs statiques.
\n
• Le GC ne peut pas supprimer un objet qui a encore une référence (même si vous l'avez oubliée).
\n
• Les différents algorithmes de GC ont des objectifs différents : pauses minimales, débit maximal ou économie de mémoire.
\n

Voici un exemple classique de fuite mémoire, lorsqu'un objet est « oublié » dans une collection :

public class LeakExample {\n    private static List<byte[]> cache = new ArrayList<>();\n\n    public static void addToCache() {\n        byte[] data = new byte[1024 * 1024]; // 1 Mo\n        cache.add(data); // La référence reste — le GC n'y touchera pas\n    }\n\n    public static void main(String[] args) {\n        for (int i = 0; i < 1000; i++) {\n            addToCache();\n        }\n        // Ici, il y aura OutOfMemoryError, bien que les objets ne soient plus nécessaires\n    }\n}\n

Conclusion : la mémoire en Java ne sera pas libérée tant que vous conservez une référence. Comprendre cela est le premier pas vers l'écriture d'un code efficace.

Types de ramasse-miettes en Java : de Serial à ZGC

Le Java moderne propose plusieurs implémentations du garbage collection Java. Le choix dépend de vos besoins :

1. Serial GC — pour les petites applications

Un ramasse-miettes monothread qui « gèle » toute l'application. Utilisé par