Apprentissage de la machine virtuelle Java - Garbage Collector
- 黄舟original
- 2017-02-17 10:42:171361parcourir
Collecteur JVM HotSpot
Il y a 7 collecteurs dessus, qui sont divisés en deux parties. La partie supérieure est le collecteur de nouvelle génération, et la partie inférieure est le collecteur d'ancienne génération. S'il existe une connexion entre deux collecteurs, ils peuvent être utilisés ensemble.
Serial (Serial GC) Collector
Serial Collector est un collecteur nouvelle génération, monothread exécution, à l'aide d'un algorithme de copie. Il doit suspendre tous les autres threads de travail (threads utilisateur) lors de l'exécution du garbage collection. Il s'agit du collecteur nouvelle génération par défaut en mode client Jvm. Pour un environnement limité à un seul processeur, le collecteur série n'a aucune surcharge d'interaction avec les threads, il peut donc naturellement atteindre la plus grande efficacité de collecte sur un seul thread en se concentrant sur le garbage collection.
Collecteur ParNew (Parallel GC)
Le collecteur ParNew est en fait une collection en série Un multi -version threadée du collecteur qui se comporte de la même manière que le collecteur Serial, sauf qu'il utilise plusieurs threads pour le garbage collection.
Collecteur Parallel Scavenge (GC de recyclage parallèle)
Collecteur Parallel Scavenge aussi Un nouveau collecteur de génération, qui est également un collecteur utilisant un algorithme de copie et un collecteur multithread parallèle. La caractéristique du collecteur Scavenge parallèle est que son objectif est différent des autres collecteurs tels que CMS est de réduire autant que possible le temps de pause du thread utilisateur pendant le garbage collection, tandis que l'objectif du collecteur Scavenge parallèle. est d'atteindre un débit contrôlé réalisable. Débit = durée d'exécution du programme/(durée d'exécution du programme, durée de récupération de place), la machine virtuelle a fonctionné pendant un total de 100 minutes. Parmi eux, le garbage collection prend 1 minute et le débit est de 99 %.
Collecteur série ancien (Serial GC)
Serial Old est la version d'ancienne génération du collecteur Serial. Il utilise également un seul thread pour effectuer la collecte et utilise l'algorithme "mark-sort". Principalement utilisé dans les machines virtuelles en mode Client.
Collecteur parallèle ancien (Parallel GC)
Parallel Old est la version ancienne génération du collecteur Parallel Scavenge, utilisant l'algorithme multi-threading et "mark-collation".
Collecteur CMS (Concurrent GC)
Le collecteur CMS (Concurrent Mark Sweep) est une méthode permettant d'obtenir le temps de collecte le plus court Le temps de pause est le collecteur cible. Le collecteur CMS est implémenté sur la base de l'algorithme « mark-clear ». L'ensemble du processus de collecte est grossièrement divisé en 4 étapes :
.
①.Marque initiale (marque initiale CMS)
②.Marque concurrente (marque concurrente CMS)
③ Remarque (remarque CMS)
.
④. Balayage simultané (balayage simultané CMS)
Les deux étapes de marquage initial et de re-marquage nécessitent toujours la mise en pause des autres fils de discussion utilisateur. Le marquage initial ne marque que les objets auxquels GC ROOTS peut s'associer directement, ce qui est très rapide. L'étape de marquage concurrent est l'étape de l'algorithme de recherche de racine GC ROOTS, qui déterminera si l'objet est vivant. La phase de remarquage consiste à corriger les enregistrements de marquage de la partie des objets qui ont été modifiés en raison de l'exécution continue du programme utilisateur pendant la période de marquage simultanée. Le temps de pause dans cette phase sera légèrement plus long que la phase de marquage initiale. , mais plus courte que la phase de marquage simultanée.
En raison des processus de marquage et d'effacement simultanés les plus longs dans l'ensemble du processus, le thread collecteur peut fonctionner avec le thread utilisateur, donc globalement, la mémoire du collecteur CMS Le processus de recyclage est exécuté simultanément avec le thread utilisateur.
Avantages du collecteur CMS : collecte simultanée, faibles pauses, mais le CMS est loin d'être parfait. Le collecteur présente principalement trois défauts importants :
Le collecteur CMS est très sensible aux ressources CPU. Dans la phase simultanée, même si cela n'entraînera pas de pause du thread utilisateur, cela occupera des ressources CPU et entraînera un ralentissement du programme de référence et une diminution du débit total. Le nombre par défaut de threads de recyclage démarrés par CMS est : (Nombre de processeurs 3) / 4.
Le collecteur CMS ne peut pas gérer les déchets flottants, et une « échec du mode simultané » peut se produire, ce qui peut conduire à un autre GC complet après un échec. Étant donné que le thread utilisateur est toujours en cours d'exécution pendant la phase de nettoyage simultanée du CMS, de nouveaux déchets continueront à être générés à mesure que le programme s'exécute et se réchauffe. Cette partie des déchets apparaît après le processus de marquage. Le CMS ne peut pas le traiter dans cette collection et doit le faire. attendez le prochain GC. Nettoyez-le. Cette partie des déchets est appelée « déchets flottants ». C'est également parce que le thread utilisateur doit encore s'exécuter pendant la phase de récupération de place,
c'est-à-dire qu'un espace mémoire suffisant doit être réservé pour que le thread utilisateur puisse l'utiliser, de sorte que le collecteur CMS ne peut pas attendre que l'ancienne génération soit presque complètement rempli avant la collecte comme les autres collecteurs, une partie de l'espace mémoire doit être réservée au fonctionnement du programme pendant la collecte simultanée. Avec les paramètres par défaut, le collecteur CMS sera activé lorsque 68 % de l'espace de l'ancienne génération est utilisé. Vous pouvez également fournir un pourcentage de déclenchement via la valeur du paramètre -XX:CMSInitiatingOccupancyFraction pour réduire le nombre de temps de recyclage de la mémoire et améliorer. performance. Si la mémoire réservée pendant le fonctionnement du CMS ne peut pas répondre aux besoins des autres threads du programme, un échec de type « Concurrent Mode Failure » se produira. À ce moment, la machine virtuelle démarrera un plan de sauvegarde : permettra temporairement au collecteur Serial Old de se reconnecter. ramasser les ordures dans l'ancienne génération, de sorte que La pause est très longue. Par conséquent, définir le paramètre -XX:CMSInitiatingOccupancyFraction trop élevé entraînera facilement une défaillance de type « Concurrent Mode Failure » et réduira les performances.Le dernier inconvénient est que CMS est un collecteur basé sur l'algorithme "mark-clear". Après la collecte à l'aide de l'algorithme "mark-clear", une grande quantité de fragments sera générée. Lorsqu'il y a trop de fragments d'espace, cela posera beaucoup de problèmes dans l'allocation des objets. Par exemple, pour les objets volumineux, l'espace mémoire ne peut pas trouver d'espace contigu à allouer et doit déclencher un GC complet à l'avance. Afin de résoudre ce problème, le collecteur CMS fournit un paramètre de commutateur -XX:UseCMSCompactAtFullCollection, qui est utilisé pour ajouter un processus de défragmentation après Full GC. Vous pouvez également utiliser le paramètre -XX:CMSFullGCBeforeCompaction pour définir le nombre de fois où effectuer une défragmentation complète non compressée. GC, suivi de Effectuer un processus de défragmentation.
Collecteur G1
Le collecteur G1 (Garbage First) est un nouveau collecteur fourni par JDK1.7. Le collecteur G1 est basé sur l'algorithme "mark-complement", ce qui signifie qu'il ne générera pas de fragmentation de la mémoire. Une autre caractéristique est que les collecteurs précédents collectaient l'intégralité de la nouvelle génération ou de l'ancienne génération, tandis que G1 collectait l'intégralité du tas Java (y compris la nouvelle génération et l'ancienne génération).
Récapitulatif des paramètres du ramasse-miettes
-XX :
-XX :--XX :
-XX :