Java garbage collection et analyse de stw dans jvm
- 黄舟original
- 2017-10-11 10:04:571794parcourir
Cet article présente principalement la compréhension rapide du garbage collection Java et du stw dans jvm, impliquant des pauses de code Java, des threads dans jvm et d'autres contenus connexes. C'est toujours très bien. Les amis qui en ont besoin peuvent s'y référer.
Le mécanisme Stop-The-World en Java est appelé STW Lors de l'exécution de l'algorithme de récupération de place, tous les autres threads de l'application Java sont suspendus (à l'exception de l'assistant de récupération de place). ). Un phénomène de pause globale en Java, pause globale, tout le code Java s'arrête, le code natif peut être exécuté, mais ne peut pas interagir avec la JVM, ces phénomènes sont principalement causés par gc ;
Stop the World (STW) pendant GC est le plus grand ennemi de chacun. Mais beaucoup de gens ne savent peut-être pas qu'en plus du GC, des pauses se produisent également sous la JVM.
Il existe un thread spécial dans la JVM - VM Threads, qui est spécialement utilisé pour effectuer certaines opérations spéciales de la VM, telles que la répartition du GC, le vidage des threads, etc. Ces tâches nécessitent l'intégralité du tas et tout threads L'état est statique et ne peut être exécuté que s'il est cohérent. Par conséquent, la JVM a introduit le concept de point de sécurité et a trouvé un moyen de notifier à tous les threads d'entrer dans un point de sécurité statique lorsque l'opération VM est requise.
En plus du GC, d'autres opérations de VM qui déclenchent des points de sécurité incluent :
1 liées au JIT, telles que la désoptimisation du code, le vidage du cache de code ; 🎜>
2. Redéfinition de classe (par exemple javaagent, instrumentation générée par l'implantation de code AOP) ;
3. La révocation du verrouillage biaisé annule le verrouillage biaisé ; Diverses opérations de débogage (par exemple, vidage de thread ou vérification de blocage)
Surveiller le point sûr pour voir ce qui est arrivé à la JVM ?
Le moyen le plus simple est d'ajouter une phrase supplémentaire aux paramètres GC des paramètres de démarrage de la JVM :
-XX:+PrintGCApplicationStoppedTime
Tous les temps de pause JVM (pas seulement GC) seront imprimés dans le journal GC.
Ceci C'est un paramètre obligatoire très utile qui peut imprimer presque n'importe quelle pause...
Cependant, dans les versions antérieures au JDK1.7.40, il n'imprimait pas d'horodatage, vous ne pouvez donc savoir que combien de temps la JVM a été mis en pause, mais je ne sais pas quand il s'est arrêté. Pour le moment, un moyen simple consiste à ajouter "-XX:+PrintGCApplicationConcurrentTime" pour imprimer le temps d'exécution normal de la JVM entre deux pauses (également sans horodatage), mais au moins il peut être utilisé avec le journal GC avec horodatage pour inverser Arrêtez. Il était temps que ça arrive.
Comment imprimer la cause du accident Et la pause ?
Ajoutez deux paramètres supplémentaires
À ce moment, quelque chose comme ceci sera imprimé dans stdout Contenu de
vmop [threads : total initial_running wait_to_block]1913.425 : GenCollectForAllocation [ 55 2 0 ] [heure : nettoyage de synchronisation du bloc de rotation vmop] page_trap_count [ 0 0 0 0 6 ] 0
Ce journal est divisé en deux sections. La première section est l'horodatage, le type d'opération de VM et l'aperçu des threads
total : le nombre total de threads. dans le point de sécurité
initially_running : le nombre de threads en cours d'exécution au début du point de sécurité
wait_to_block : le nombre de threads qui doivent attendre suspension avant le début de l'opération VM
La deuxième ligne correspond aux différentes étapes pour atteindre le point de sécurité et au temps nécessaire pour effectuer l'opération, dont la plus importante est vmop
spin : En attente que le fil réponde à l'appel
safepoint Le temps de
blocage : le temps nécessaire pour mettre tous les fils en pause
sync : égal à spin+block, qui est le temps qu'il faut depuis le début pour entrer dans le point de sécurité, peut être utilisé Déterminer le temps qu'il faut pour entrer dans le point de sécurité
nettoyage : le temps qu'il faut pour nettoyer
vmop : le temps qu'il faut pour exécuter réellement l'opération VM
On voit qu'il y en a beaucoup Cependant, les points de sécurité courts sont all RevokeBias. Pour plus de détails, consultez le principe d'implémentation du verrouillage biaisé. Les applications à haute concurrence ajoutent généralement simplement "-XX:-UseBiasedLocking" aux paramètres de démarrage pour l'annuler. De plus, j'ai également vu que certains types ne fonctionnent pas avec vm. Le document dit qu'il est garanti d'entrer dans le point de sécurité une fois par seconde (si cette seconde a déjà passé GC, ce n'est pas nécessaire), et c'est pour certains non. -les opérations urgentes qui doivent être effectuées dans le point sûr. Par exemple, certains outils de profilage d'échantillonnage peuvent être ajustés avec -DGuaranteedSafepointInterval, mais en réalité cela ne se produit pas toutes les secondes et le temps est variable.
En combat réel, nous avons utilisé des journaux de points de sécurité et avons constaté que les programmes appelaient régulièrement Thread Dump, etc. Cependant, comme le journal des points de sécurité est affiché par défaut sur la sortie standard, nous ne l'activons généralement pas par défaut en raison des performances et de la propreté du journal de la sortie standard. Ouvert uniquement en cas de besoin.
Ajoutez les trois paramètres suivants pour en savoir plus sur ce qui se passe dans la VM. Malheureusement, la JVM ne transférera pas le journal des points de sécurité vers vm.log simplement parce que ces trois paramètres sont définis, mais l'imprimera deux fois en vain.
Résumé
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!