Garbage Collection en Java : progrès depuis JDK 8

Depuis JDK 8, le garbage collection (GC) de Java a subi une évolution significative, répondant à des défis courants tels que la latence, les temps de pause et la surcharge de mémoire. Cet article explore ces avancées, en se concentrant sur les implications pratiques pour les développeurs passant de versions plus anciennes comme JDK 8 à des alternatives modernes telles que JDK 17 et JDK 21. Que vous mainteniez des applications existantes ou planifiiez de futures migrations, il est crucial de comprendre ces mises à jour.

Points clés

1. Améliorations depuis JDK 8 : les versions plus récentes du JDK offrent des améliorations significatives en termes de gestion de la mémoire et de performances des applications.
2. Comprendre les options GC : choisir le bon ramasse-miettes pour votre application peut optimiser le comportement et l'utilisation des ressources.
3. Mises à jour incrémentielles : des avancées telles que les modes GC générationnels et la disposition des tas basées sur les régions ont transformé le garbage collection, offrant une meilleure évolutivité et efficacité.

Garbage Collection (GC) en Java automatise la gestion de la mémoire, libérant ainsi les développeurs de la gestion des détails de bas niveau. Les deux principaux objectifs de GC sont :

1. Allocations rapides : Java utilise des tampons d'allocation locale de thread (TLAB) pour des allocations de mémoire rapides et sans synchronisation.
2. Récupération efficace : les algorithmes GC récupèrent la mémoire inutilisée grâce à des techniques telles que le compactage et les listes libres.

Le Java GC moderne divise le tas en deux générations :

• Jeune génération : stocke des objets éphémères, où les collectes sont fréquentes mais rapides.
• Ancienne génération : stocke les objets à longue durée de vie qui survivent à plusieurs cycles GC.

Cette division est basée sur l'hypothèse générationnelle, qui postule que la plupart des objets meurent jeunes, ce qui rend les collections de la jeune génération plus efficaces que les collections en tas complet. Java fournit plusieurs algorithmes GC, chacun adapté à des cas d'utilisation spécifiques :

Éboueur Concentration Cas d'utilisation Temps de pause Débit ête>

Garbage Collector	Focus	Use Case	Pause Time	Throughput
Serial GC	Low memory overhead	Small containers	Medium	Low
Parallel GC	High throughput	Batch processing or large datasets	High	High
G1 GC	Balanced performance	General-purpose, low-latency workloads	Medium-Low	Medium-High
ZGC	Ultra-low latency	Large-scale applications, low latency	Sub-millisecond	Medium
Shenandoah GC	Low latency	Large heaps, near-real-time processing	Very low	Medium

GC série Faible surcharge de mémoire Petits conteneurs Moyen Faible GC parallèle Haut débit Traitement par lots ou grands ensembles de données Élevé Élevé G1 GC Performances équilibrées Charges de travail à usage général et à faible latence Moyen-Faible Moyen-Élevé ZGC Latence ultra-faible Applications à grande échelle, faible latence Sous-milliseconde Moyen Shenandoah GC Faible latence Grands tas, traitement en temps quasi réel Très faible Moyen

Introduit comme collecteur par défaut dans JDK 9, G1 GC utilise une disposition de tas basée sur la région et prend en charge le marquage simultané. Cela lui permet de déterminer l’activité sans arrêter les threads d’application. En combinant les collections jeunes et anciennes générations dans des collections mixtes plus petites, G1 réduit les temps de pause et améliore la réactivité globale.

Conçu pour une latence ultra-faible, ZGC peut gérer des tas de la taille d'un téraoctet avec des temps de pause de l'ordre de la milliseconde. Il effectue la plupart de son travail simultanément avec les threads d'application, ce qui le rend idéal pour les applications nécessitant une réactivité constante, telles que les services cloud ou les systèmes financiers.

Le mode générationnel ZGC (introduit dans JDK 21) améliore encore le débit en appliquant l'hypothèse générationnelle pour séparer les objets à durée de vie courte et longue.

Des benchmarks tels que SPECjbb 2015 démontrent des améliorations substantielles du débit et de la latence des algorithmes GC modernes depuis JDK 8 :

• GC Parallèle : 30 % d'amélioration du débit du JDK 8 au JDK 17.
• G1 GC : Amélioration de plus de 40 % du débit du JDK 8 au JDK 17.
• ZGC : 10% d'amélioration avec le mode générationnel dans JDK 21.

Temps de pause réduits

Les temps de pause ont été considérablement réduits sur tous les collecteurs :

• GC parallèle : De ~100 ms à ~65 ms.
• G1 GC : 40% de réduction du JDK 8 au JDK 17.
• ZGC : pauses inférieures à la milliseconde.

G1 GC a constaté des réductions significatives de la surcharge de mémoire native, grâce à des optimisations dans les ensembles mémorisés, les structures de données utilisées pour les collections basées sur les régions. Du JDK 8 au JDK 17, l'utilisation de la mémoire native du G1 a été réduite de près de moitié. Pour mieux illustrer les aspects pratiques du GC, considérons les exemples suivants :

Exemple 1 : configuration du G1 GC

# Add these options to your JVM startup command
java -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -Xmx2g -Xms2g -jar app.jar

Cette configuration :

• Active le G1 GC.
• Définit un temps de pause maximum cible de 50 ms.
• Alloue 2 Go de mémoire tas.

Optimisation de ZGC pour les applications à faible latence

java -XX:+UseZGC -Xms4g -Xmx4g -XX:SoftRefLRUPolicyMSPerMB=50 -jar app.jar

Cette configuration :

• Utilise ZGC pour une latence ultra-faible.
• Alloue 4 Go de mémoire tas.
• Ajuste la durée de vie des références logicielles pour une meilleure gestion de la mémoire.

Défis de la migration au-delà de JDK 8

Bien que la mise à niveau du JDK 8 vers une version plus récente (par exemple, JDK 17 ou 21) puisse apporter des avantages significatifs, les développeurs doivent prendre en compte :

• Problèmes de compatibilité : Certaines bibliothèques ou frameworks peuvent ne pas prendre entièrement en charge les versions plus récentes du JDK.
• Réglage des performances : Chaque GC possède des paramètres de réglage spécifiques qui peuvent nécessiter un ajustement pour des performances optimales.
• Tests de l'environnement de préparation : effectuez toujours des tests approfondis dans des environnements de non-production avant de déployer les modifications.

Les progrès du garbage collection de Java depuis JDK 8 ont été remarquables. Avec des améliorations significatives en termes de débit, de latence et de surcharge de mémoire, la mise à niveau vers des versions plus récentes du JDK est nécessaire pour toute application Java.

Que vous utilisiez de petits conteneurs ou des services cloud à grande échelle, il existe un algorithme GC optimisé pour votre cas d'utilisation. Donc, si vous utilisez toujours le JDK 8, il est temps de faire le grand saut et de profiter des avantages en termes de performances du Java moderne.

Pour plus d'informations, regardez cette vidéo de Devoxx Belgium sur le Garbage Collection en Java : les progrès depuis le JDK 8 par Stefan Johansson

?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!