GC en série
La récupération de place améliore l'efficacité de la mémoire en Java en supprimant les objets non référencés du tas et en faisant de la place pour les objets nouvellement créés.
La machine virtuelle Java possède huit types de ramasse-miettes. Considérons chacun d'eux en détail.
Serial GC est la mise en œuvre de GC la plus simple. Il est destiné aux petites applications s'exécutant dans des environnements monothread. Tous les événements de récupération de place sont exécutés séquentiellement sur le même thread. Le compactage est effectué après chaque récupération de place.
L'exécution du collecteur entraîne un événement "arrêt mondial", où toute l'application est suspendue. Étant donné que l'ensemble de l'application est gelé lors de la récupération de place, vous ne devriez pas y recourir dans la vraie vie si vous souhaitez réduire au maximum les retards.
L'argument JVM pour utiliser le ramasse-miettes série est -XX:+UseSerialGC .
GC parallèle
Le garbage collector parallèle est conçu pour les applications avec des ensembles de données moyens à volumineux qui s'exécutent sur du matériel multithread ou multiprocesseur. Il s'agit de l'implémentation GC par défaut et est également connue sous le nom de collecteur de débit.
Plusieurs threads sont destinés au petit ramasse-miettes de la jeune génération. Le seul thread est occupé par le ramasse-miettes principal de l'ancienne génération.
L'exécution d'un GC parallèle provoque également l'arrêt du monde et l'application se bloque. Ce comportement est plus approprié pour un environnement multithread où de nombreuses tâches doivent être effectuées et où de longues pauses sont acceptables, comme lors de l'exécution d'un travail par lots.
L'argument JVM pour utiliser le ramasse-miettes parallèle est -XX:+UseParallelGC .
GC CMS
Également connu sous le nom de sélecteur parallèle à repos bas .
Ici, pour un petit ramasse-miettes, plusieurs threads sont impliqués, cela passe par le même algorithme que dans le collecteur parallèle. Le ramasse-miettes principal est multithread, tout comme l'ancien GC parallèle, mais le CMS s'exécute en même temps que les processus d'application pour minimiser les événements "d'arrêt mondial".
Pour cette raison, le collecteur CMS consomme plus de CPU que les autres collecteurs. Si vous avez la possibilité d'allouer plus de CPU pour améliorer les performances, alors un CMS est préférable à un simple collecteur parallèle. Le CMS GC ne se compacte pas.
L'argument JVM pour utiliser le ramasse-miettes parallèle de balayage de marques est -XX:+UseConcMarkSweepGC .
G1 (Déchets d'abord) GC
G1GC a été conçu pour remplacer CMS et a été développé pour les applications multithread qui se caractérisent par de grandes tailles de tas (supérieures à 4 Go). Il est parallèle et compétitif comme un CMS, mais sous le capot, il fonctionne très différemment des anciens éboueurs.
Bien que G1 fonctionne également sur une base générationnelle, il ne dispose pas d'espaces séparés pour les générations plus jeunes et plus âgées. Au lieu de cela, chaque génération est un ensemble de régions, permettant une flexibilité dans le changement de la taille de la jeune génération.
G1 divise le tas en un ensemble de régions de taille égale (en fonction de la taille du tas) et les analyse en plusieurs threads. La zone pendant l'exécution du programme peut devenir à plusieurs reprises à la fois vieille et jeune.
Une fois la phase de balisage terminée, G1 sait quelles zones contiennent le plus de déchets. Si l'utilisateur souhaite minimiser les pauses, G1 ne peut sélectionner que quelques zones. Si le temps de pause n'est pas important pour l'utilisateur, ou si la limite de temps de pause est élevée, G1 parcourra plus de zones.
Étant donné que le GC G1 identifie les régions avec le plus de déchets et effectue d'abord la récupération de place sur ces régions, il s'appelle "Garbage First".
En plus des zones Eden, Survivors et Old Memory, il existe deux autres types dans G1GC.
- Humongous (Huge) - pour les objets de grande taille (plus de 50% de la taille du tas).
- Disponible - Espace inutilisé ou non alloué.
L'argument JVM pour utiliser le ramasse-miettes G1 est -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah est un nouveau GC publié dans le cadre de JDK 12. Le principal avantage de Shenandoah par rapport à G1 est que la majeure partie du cycle de récupération de place est effectuée en même temps que les threads d'application. G1 ne peut évacuer les zones de tas que lorsque l'application est suspendue, tandis que Shenandoah déplace les objets en même temps que l'application.
Shenandoah peut compacter des objets vivants, nettoyer les déchets et libérer de la RAM presque dès que de la mémoire libre est trouvée. Étant donné que tout cela se produit en même temps, sans suspendre l'application, Shenandoah est plus gourmand en CPU.
ZGC
ZGC est un autre GC publié dans le cadre du JDK 11 et amélioré dans le JDK 12.
Il est destiné aux applications nécessitant de la rapidité et une faible latence (pauses inférieures à 10 ms) et/ou utilisant un tas très important (plusieurs téraoctets).
Les principaux objectifs de ZGC sont une faible latence, l'évolutivité et la facilité d'utilisation. Pour ce faire, il permet à l'application Java de continuer à s'exécuter malgré le fait que des opérations de récupération de place sont en cours. Par défaut, ZGC libère la mémoire inutilisée et la renvoie au système d'exploitation.
Ainsi, le ZGC apporte une amélioration significative par rapport aux autres GC traditionnels en offrant des temps morts extrêmement faibles (généralement inférieurs à 2 ms).
L'argument JVM pour utiliser le ramasse-miettes ZGC est -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .