7 types de ramasse-miettes pour Java

Une application écrite à l’aide de langages de programmation tels que C et C++ vous oblige à programmer la destruction d’objets en mémoire lorsqu’ils ne sont plus nécessaires. Plus votre application grandit, plus la probabilité que vous négligez de libérer des objets inutilisés est grande. Cela conduit à une fuite de mémoire et finalement la mémoire système est épuisée, et à un moment donné, il n’y a plus de mémoire à allouer. Il en résulte une situation où l’application échoue avec une OutOfMemoryError. Mais dans le cas de Java, Garbage Collection (GC) se produit automatiquement lors de l’exécution de l’application, ce qui réduit la tâche de désallocation manuelle et les éventuelles fuites de mémoire.

Garbage Collection n’est pas une tâche unique. La machine virtuelle Java (JVM) a huit types différents de Garbage Collection, et il est utile de comprendre le but et la force de chacun.

1. Série GC

Une implémentation primitive de GC utilisant un seul thread. Lorsque Garbage Collection se produit, il met l’application en pause (communément appelé événement “stop the world”.) Cela convient aux applications qui peuvent supporter de petites pauses. Garbage Collection a un faible encombrement, il s’agit donc du type de GC préféré pour les applications embarquées. Ce style Garbage Collection peut être activé lors de l’exécution :

$ java -XX:+UseSerialGC

2. GC parallèle

Comme Serial GC, cela utilise également une méthode “stop the world”. Cela signifie que pendant que GC se produit, les threads d’application sont suspendus. Mais dans ce cas, plusieurs threads effectuent une opération GC. Ce type de GC convient aux applications avec des ensembles de données moyens à grands exécutés dans un environnement multithread et multiprocesseur.

Il s’agit du GC par défaut dans JVM, également connu sous le nom de Collecteur de débit. Divers paramètres GC, tels que le débit, le temps de pause, le nombre de threads et l’empreinte, peuvent être réglés avec des indicateurs JVM appropriés :

• Le nombre de fils: -XX:ParallelGCThreads=<N>
• Le temps de pause: -XX:MaxGCPauseMillis=<N>
• Débit (temps passé pour GC par rapport à l’exécution réelle de l’application) : -XX:GCTimeRatio=<N>
• Empreinte de tas maximale : -Xmx<N>
• Le GC parallèle peut être explicitement activé : java -XX:+UseParallelGC. Avec cette option, le GC mineur dans la jeune génération se fait avec plusieurs threads, mais le GC et le compactage se font avec un seul thread dans l’ancienne génération.

Il existe également une version de Parallel GC appelée Ancien GC parallèlequi utilise plusieurs threads pour les jeunes et les anciennes générations :

$ java -XX:+UseParallelOldGC

3. Balayage simultané de marques (CMS)

La récupération de place Concurrent Mark Sweep (CMS) est exécutée parallèlement à une application. Il utilise plusieurs threads pour les GC mineurs et majeurs. Le compactage des objets actifs n’est pas effectué dans CMS GC après la suppression des objets inutilisés, de sorte que le temps de pause est inférieur à celui des autres méthodes. Ce GC s’exécute en même temps que l’application, ce qui ralentit le temps de réponse de l’application. Ceci convient aux applications avec un faible temps de pause. Ce GC était obsolète dans Java 8u et complètement supprimé à partir de 14u. Si vous utilisez toujours une version Java qui l’a, vous pouvez l’activer avec :

$ java -XX:+UseConcMarkSweepGC

Dans le cas de CMS GC, l’application est mise en pause deux fois. Il est mis en pause en premier lorsqu’il marque un objet actif directement accessible. Cette pause est connue sous le nom de marque initiale. Il est mis en pause une deuxième fois à la fin de la phase CMS GC, pour tenir compte des objets qui ont été manqués pendant le cycle simultané, lorsque les threads d’application ont mis à jour les objets après la fin du CMS GC. Ceci est connu comme le phase de remarque.

4. G1 (Garbage First) GC

Garbage first (G1) devait remplacer CMS. G1 GC est un compactage parallèle, simultané et incrémentiel, avec un faible temps de pause. G1 utilise une disposition de mémoire différente de CMS, divisant la mémoire de tas en régions de taille égale. G1 déclenche une phase de marquage globale avec plusieurs threads. Une fois la phase de marquage terminée, G1 sait quelle région pourrait être principalement vide et choisit d’abord cette région pour une phase de balayage/suppression.

Dans le cas de G1, un objet dont la taille est supérieure à la moitié d’une région est considéré comme un “objet gigantesque”. Ces objets sont placés dans l’ancienne génération, dans une région appelée à juste titre la région gigantesque. Pour activer G1 :

$ java -XX:+UseG1GC

5. EpsilonGC

Ce GC a été introduit en 11u et est un pas d’opération (ne rien faire) GC. Epsilon gère uniquement l’allocation de mémoire. Il ne fait aucune récupération de mémoire réelle. Epsilon est destiné uniquement lorsque vous connaissez l’empreinte mémoire exacte de votre application et que vous savez qu’elle est exempte de récupération de place.

$ java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

6. Shenandoah

Shenandoah a été introduit dans JDK 12 et est un GC gourmand en CPU. Il effectue le compactage, supprime les objets inutilisés et libère immédiatement de l’espace libre sur le système d’exploitation. Tout cela se produit en parallèle avec le thread d’application lui-même. Pour activer Shenandoah :

$ java -XX:+UnlockExperimentalVMOptions \ 
-XX:+UseShenandoahGC

7. ZGC

ZGC est conçu pour les applications qui ont des exigences de faible latence et utilisent de grands tas. ZGC permet à une application Java de continuer à s’exécuter pendant qu’elle effectue toutes les opérations de récupération de place. ZGC a été introduit dans JDK 11u et amélioré dans JDK 12. Shenandoah et ZGC ont été retirés de la phase expérimentale à partir de JDK 15. Pour activer ZGC :

$ java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC

Collecte flexible des ordures

Java offre une flexibilité pour la gestion de la mémoire. Il est utile de se familiariser avec les différentes méthodes disponibles afin de pouvoir choisir celle qui convient le mieux à l’application que vous développez ou exécutez.