Le garbage collector (GC) de la Java Virtual Machine (JVM) est un composant clé de la plateforme Java, qui permet aux programmeurs de se concentrer sur la logique de leur application sans avoir à gérer manuellement la mémoire.
Dans cet article, nous allons examiner de plus près le fonctionnement du GC dans la JVM.
Comprendre la gestion de la mémoire dans la JVM
Avant de plonger dans le fonctionnement du GC de la JVM, il est important de comprendre comment la gestion de la mémoire fonctionne dans la plateforme Java.
En Java et Kotlin, les objets sont créés sur le tas (heap), une zone de mémoire qui est partagée entre tous les threads de l’application. Le tas est divisé en deux zones principales : la zone jeune (young generation) et la zone ancienne (old generation).
La zone jeune est l’endroit où les objets nouvellement créés sont stockés. Elle est subdivisée en deux espaces : l’espace d’Eden (Eden space) et les espaces de survie (survivor spaces). Les objets qui survivent à une collection de la zone jeune sont promus dans la zone ancienne.
La zone ancienne est l’endroit où les objets qui ont survécu à plusieurs cycles de collection dans la zone jeune sont stockés. Elle est également subdivisée en deux espaces : l’espace permanent (permanent space) et l’espace de mémoire de la pile (stack memory).
Les différents types de garbage collector dans la JVM
La JVM dispose de différents types de garbage collector, chacun étant optimisé pour différents types d’applications et d’environnements. Les types de garbage collector suivants sont disponibles dans la JVM :
- Le garbage collector par défaut (Serial GC) : ce garbage collector est conçu pour les applications à faible utilisation de la mémoire, les applications monothread, ou les petits serveurs. Il utilise une stratégie de collection basée sur la marque et le balayage, et est relativement simple à configurer.
- Le garbage collector parallèle (Parallel GC) : ce garbage collector est conçu pour les applications à forte utilisation de la mémoire, les applications multithreads, ou les serveurs de taille moyenne à grande. Il utilise une stratégie de collection basée sur la marque et le balayage, et fonctionne en parallèle sur plusieurs threads pour améliorer les performances.
- Le garbage collector CMS (Concurrent-Mark Sweep GC) : ce garbage collector est conçu pour les applications avec des temps de réponse rapides, où la latence est un facteur critique. Il utilise une stratégie de collection basée sur la marque et le balayage, et fonctionne en arrière-plan pour minimiser la durée de la pause de collection.
- Le garbage collector G1 (Garbage-First GC) : ce garbage collector est conçu pour les applications avec une utilisation de la mémoire élevée et des contraintes de temps de réponse strictes. Il utilise une stratégie de collection basée sur la marque et le balayage, et fonctionne en parallèle sur plusieurs threads pour améliorer les performances. Il utilise également une stratégie de tri de tas pour optimiser les performances de la collection.
Fonctionnement du garbage collector dans la JVM
Le GC dans la JVM est un processus continu qui s’exécute en arrière-plan, recherchant les objets qui ne sont plus référencés par le programme et les marquant pour la suppression. Le processus de nettoyage est déclenché lorsque la JVM détecte que l’espace disponible sur le tas est devenu insuffisant pour accueillir de nouveaux objets. Le GC utilise alors l’une des stratégies de collecte disponibles pour libérer l’espace occupé par les objets non référencés.
Dans la zone jeune, le GC utilise généralement une stratégie de collection basée sur le comptage de références. Cette stratégie utilise un compteur de références pour suivre le nombre de fois qu’un objet est référencé. Lorsque l’objet n’a plus de références, le GC le marque comme candidat à la suppression. Les objets qui ont survécu à plusieurs cycles de collection dans la zone jeune sont promus dans la zone ancienne, où une stratégie de collection différente est utilisée.
Dans la zone ancienne, le GC utilise généralement une stratégie de collection basée sur le marquage et le balayage. Cette stratégie consiste à marquer tous les objets encore référencés, puis à balayer la mémoire pour supprimer les objets non marqués. Cependant, cette stratégie peut entraîner des pauses de la JVM pendant la collecte, ce qui peut affecter les performances de l’application.
Le garbage collector CMS utilise une stratégie de collection plus complexe basée sur la marque et le balayage. Cette stratégie consiste à marquer tous les objets encore référencés, puis à effectuer une collection partielle pour supprimer les objets non marqués. Pendant la collection, l’application continue de fonctionner en arrière-plan, ce qui minimise les pauses de la JVM.
Le garbage collector G1 utilise une stratégie de tri de tas pour optimiser les performances de la collection. Cette stratégie consiste à trier les objets sur le tas en fonction de leur taille et de leur durée de vie prévue, puis à effectuer une collection partielle pour supprimer les objets qui ne sont plus référencés. Cette stratégie peut améliorer les performances de la collecte en réduisant le nombre d’objets à traiter.
Configurer le GC dans la JVM
La JVM offre une grande flexibilité pour configurer le GC en fonction des besoins de l’application. Les options de configuration peuvent être passées à la JVM via la ligne de commande ou via des fichiers de configuration. Les options de configuration les plus courantes sont les suivantes :
- -Xmx : définit la taille maximale de la mémoire allouée à la JVM.
- -Xms : définit la taille initiale de la mémoire allouée à la JVM.
- -XX:+UseSerialGC : active le garbage collector par défaut.
- -XX:+UseParallelGC : active le garbage collector parallèle.
- -XX:+UseConcMarkSweepGC : active le garbage collector CMS.
- -XX:+UseG1GC : active le garbage collector G1.
Il est important de noter que la configuration optimale du GC dépend de nombreux facteurs, tels que la taille de l’application, le nombre de threads, la fréquence d’allocation d’objets, etc.
Les tests de performance doivent être effectués pour déterminer la configuration optimale pour une application donnée.
En plus de la configuration de base, la JVM offre également des options avancées pour affiner les performances du GC. Ces options peuvent être utilisées pour ajuster les paramètres de collection, tels que la fréquence de collection, le seuil de promotion, la taille de la zone jeune, etc.
Conclusion
Le garbage collector de la JVM est un composant clé qui permet aux développeurs de se concentrer sur la logique de leur application sans avoir à gérer manuellement la mémoire. La JVM offre une grande flexibilité pour configurer le GC en fonction des besoins de l’application, avec différents types de GC et des options de configuration avancées. Il est important de comprendre le fonctionnement du GC dans la JVM pour tirer le meilleur parti des performances de l’application.
