Dans cet article, je vais vous apprendre à analyser la pile de threads de JVM et comment trouver la cause profonde du problème à partir des informations de la pile. À mon avis, la technologie d'analyse de pile de threads est une technologie que les ingénieurs de soutien aux produits Java EE doivent maîtriser. Les informations stockées dans la pile de threads sont généralement bien au-delà de votre imagination.
Mon objectif est de partager les connaissances et l'expérience accumulées dans l'analyse de fil au cours des dix dernières années. Ces connaissances et ces expériences sont obtenues dans l'analyse en profondeur de diverses versions de JVM et des fournisseurs JVM de divers fabricants.
Alors, êtes-vous prêt, maintenant cet article est ajouté au signet. Qu'attendez-vous, veuillez dépêcher et partager ce plan de formation d'analyse de fil avec vos collègues et amis.
Cela semble bon.
Ma suggestion est de me suivre pour terminer ce plan de formation d'analyse de fil. Voici le contenu de formation que nous couvrirons. En même temps, je partagerai avec vous les cas réels avec lesquels j'ai traité pour tout le monde pour apprendre et comprendre avec tout le monde.
1) Aperçu des piles de threads et des connaissances de base
2) Principes et outils connexes de pile de threads
3) Différents formats de pile de fil JVM (Sun Hotspot, IBM JRE, Oracal Jrockit)
4) Méthode d'introduction et d'analyse du journal de pile de threads
5) Analyse des piles de threads et des technologies connexes
6) Modèles de problèmes courants (filetage, serrures mortes, IO appelant la mort, le recyclage des ordures / le problème de l'OutofMemoryerror, le cycle mort, etc.)
7) Par exemple l'analyse des problèmes de pile de threads
J'espère que cette série de formation vous apportera une véritable aide, alors continuez à faire attention à la mise à jour hebdomadaire des articles.
Mais que dois-je faire si j'ai des questions dans le processus d'étude ou si je ne comprends pas le contenu de l'article?
Ne vous inquiétez pas, traitez-moi simplement comme votre mentor. Vous pouvez me consulter toutes les questions sur la pile de threads (à condition que le problème ne puisse pas être trop bas). Veuillez sélectionner les façons suivantes de me contacter:
1) directement commenté dans cet article (si vous êtes désolé, vous pouvez être anonyme)
2) Soumettez vos données de pile de threads au forum d'analyse des causes profondes
3) Envoyez-moi un e-mail, l'adresse est @ phcharbonneau @ hotmail.com
Pouvez-vous m'aider à analyser les problèmes rencontrés sur nos produits?
Bien sûr, si vous le souhaitez, vous pouvez m'envoyer vos données en direct par empilement par courrier ou forum Root Capes Analysis Forum. Le problème réel est le roi d'apprendre à améliorer les compétences.
J'espère vraiment que tout le monde pourra aimer cette formation. Je ferai donc de mon mieux pour vous fournir des documents de haute qualité et répondre à vos différentes questions.
Avant d'introduire la technologie d'analyse de pile de threads et le modèle de problème, vous devez d'abord vous dire le contenu de base. Donc, dans cet article, je couvrirai le contenu le plus élémentaire, afin que tout le monde puisse mieux comprendre l'interaction entre les conteneurs JVM, middleware et Java EE.
Présentation de Java VM
Java Virtual Machine est la base de la plate-forme Jave EE. C'est l'endroit où le middleware et les applications sont déployés et s'exécutent.
JVM fournit les choses suivantes au logiciel Middleware et à votre programme Java / Java EE:
(Formulaire binaire) Java / Java EE Programme Environnement de fonctionnement Certains caractéristiques et outils fonctionnels du programme (infrastructure IO, structure de données, gestion de threads, sécurité, surveillance, etc.).)
Attribution et gestion dynamique de la mémoire à l'aide de la récupération des ordures
Votre JVM peut rester sur de nombreux systèmes d'exploitation (Solaris, AIX, Windows, etc.) et peut être configuré en fonction de votre serveur physique.
Interaction entre JVM et middleware
Le diagramme suivant montre le modèle interactif à élection élevée entre JVM, middleware et applications.
Quelques interactions simples et typiques entre le JVM, le middleware et les applications affichées sur la figure. Comme vous pouvez le voir, l'allocation des threads de l'application Java EE standard est complétée entre le cœur de la partie centrale et JVM. (Bien sûr, il y a des exceptions. L'application peut appeler directement l'API pour créer un fil. Cette approche n'est pas courante, et il est nécessaire d'être prudent pendant l'utilisation)
En même temps, veuillez noter que certains fils sont gérés par JVM.
Étant donné que la plupart des diffusions de threads sont effectuées par le conteneur Java EE, il est important de comprendre et de comprendre le suivi de la pile de threads, et peut les identifier à partir des données de pile de threads, ce qui est important pour vous. Les demandes sont sur le point d'exécuter le conteneur Java EE.
Du point de vue de l'analyse d'une pile de stockage de threads, vous pourrez comprendre la différence entre le pool de threads découvert à partir de JVM et identifier le type de demande.
La dernière section vous fournira un aperçu de la pile de threads JVM pour HOTSOP V vous fournir.
Veuillez noter que vous pouvez obtenir un exemple de pile de threads pour cet article à partir des raisons fondamentales.
JVM Thread Stack - Qu'est-ce que c'est?
La pile de threads JVM est un instantané de temps donné qui peut vous fournir une liste complète de tous les threads Java créés.
Chaque fil Java trouvé vous donnera les informations suivantes:
Le nom du thread;
Type de thread et priorité, par exemple: Daemon PRIO = 3 ** Le programme middleware crée généralement leurs threads sous forme de tutelle de fond, ce qui signifie que ces threads fonctionnent en arrière-plan; À votre application Java EE **
ID de thread Java, tel que: tid = 0x000000011e52a800 ** Il s'agit de l'ID de thread Java obtenu via java.lang.thread.getID ().
ID de thread natif, tel que: NID = 0x251c **, la clé est parce que l'ID de thread natif vous permet de vous obtenir du point de vue du système d'exploitation.
État du thread Java et informations détaillées, telles que: en attente de l'entrée du moniteur [0xffffffFFEA5AFB000] java.lang.thread.state: Block (sur moniteur d'objet)
** Vous pouvez rapidement comprendre la raison possible pour laquelle l'état du thread est extrêmement bloqué **
Le suivi de la pile de threads Java; Cause de nombreux types de problèmes, 90% des informations requises.
Décomposition de la mémoire de la pile Java; en commençant par la version Hotspot VM 1.6, l'utilisation de la mémoire de Hotspot peut être vue à la fin de la pile de threads, comme la mémoire empilée de Java (YounGgen, Oldgen) et Permgen. Ces informations sont très utiles lors de l'analyse des problèmes causés par des GC fréquents. Vous pouvez utiliser les données ou le mode de thread connus pour effectuer un positionnement rapide.
HeappSyggen Total 466944K, utilisé 178734K [0xffffffffff45c00000, 0xffffffffffffffffffffffffffr FFFFFFFFFF62400000, 0xfffffff62400000,0xfffffffffff70800000) E 233472K, 0% UserD [0xffffffff54000000, 0xffffffff5400000000 , 0xfffffffff62400000) Psoldgen Total 1400832K, utilisé 1400831K [0xffffffffff0400000) espace objet 1400832k, 99% utilisé [0xFFFFFFFFFFFFFFFFF0400000, 0xFFFFFFFFFFFFFFFFFFFFI 00000) PSPERMGEN TOTAL 262144K, utilisé 248475K, 0xffffffee0400000, 0xffffffff0400000) Espace d'objet 262144K, 94% utilisé [0xFFFFFFFFED0400000 , 0xffffffedf6f08,0xffffffffffee0400000)
GRAND DÉMISSEMENT D'INFORMATIONS DE LA PILE DE TIFE
Afin de permettre à tout le monde de mieux comprendre, l'image suivante est fournie à tout le monde.
Dans la figure ci-dessus, on peut voir que la pile de threads est composée de plusieurs parties différentes. Ces informations sont importantes pour l'analyse du problème, mais l'analyse du mode de problèmes différents utilisera différentes parties (le mode problème simulera et démontrera dans les articles ultérieurs.)
Maintenant, grâce à cet exemple d'analyse, j'expliquerai en détail les composants du motespot sur les informations de pile à thread:
# Vidage complet
"Full Thread Dump" est un mot clé global uniquement. Ceci est le début de l'instantané de la pile de threads.
Vidage complet du vidage Java Hotspot (TM) VM du serveur 64 bits (mode mixte 20.0-b11):
# Java EE Middleware, tiers et threads dans un logiciel d'application personnalisé
Cette partie est la partie centrale de toute la pile de threads, et c'est aussi la partie qui doit généralement analyser le temps. Le nombre de lignes intermédiaires de pile dépend du middleware que vous utilisez, d'une bibliothèque de troisième partie (peut avoir des threads indépendants) et de votre application (si vous créez un thread personnalisé, ce n'est généralement pas une bonne pratique).
Dans notre exemple de pile de threads, WebLogic est le middleware que nous utilisons. À partir de WebLogic 9.2, vous utiliserez le pool de fils unique qui peut être géré par "
"[Standby] ExecuteThead: '414' pour la file d'attente: 'weblogic.kernel.default (auto-tuning)' 'Daemon Prio = 3 tid = 0x000000010916a800 nid = 0x2613 dans objet .wait () [0xffffffffffe9edff000] java.lang.thread. État: en attente (sur moniteur d'objet) sur java.lang.object.wait (méthode native) -Waiting sur <0xffffff27d44de0> (a weblogic.work.executeTethread). Work.work.cutethread.waitForRequest (exécuthread.java:160) -locked <0xffffffff27d44de0> (a weblogic.work.executeTheread) c.work.executethread.run (exécutheTheread.java:181)
# Thread VM Hotspot
Il s'agit d'un thread interne géré par Hotspot VM pour l'opération native des opérations internes. Généralement, vous n'avez pas à faire trop à ce sujet, sauf si vous trouvez un taux d'occupation CPU élevé à moins que vous (via des piles de threads connexes et PRSTAT ou ID de fil natif).
"VM Tâche périodique Thread" PRIO = 3 TID = 0x0000000101238800 NID = 0x19 en attente de l'état
# Thread GC Hotspot
Lorsque vous utilisez Hotspot pour GC parallèle (maintenant il est courant dans l'environnement de plusieurs cœurs physiques), lorsque la machine hotspot créée par défaut, ou chaque JVM gère un thread GC avec un logo spécifique. Le nettoyage de GC périodique entraînera la réduction globale du temps de GC;
"Thread de la tâche GC # 0 (parallelgc)" prio = 3 tid = 0x0000000100120000 NID = 0x3 Runnable "GC Task Thread # 1 (parallelgc)" prio = 3 tid = 0x0000131000 NID = 0x444 Runnable ……………………… ……………………………………… ………………………………………………………………………………………… …………………………………………………………
Il s'agit d'une donnée critique, car lorsque vous rencontrez des problèmes liés à GC, tels que des fuites de GC et de mémoire excessives, vous pourrez utiliser le système d'exploitation ou le thread Java associé à la valeur d'ID native de ces threads, puis à trouver tout droit À droite.
# JNI Nombre de références globales
La référence globale de JNI (interface locale Java) est du code local à l'objet de base de l'objet Java géré par le collecteur Java Garbage. Collection des ordures.
En même temps, il est également important de faire attention aux références JNI pour détecter les fuites liées à JNI.
JNI références mondiales: 1925
# Java Stack Utiliser la vue
Ces données ont été ajoutées à JDK 1.6, vous fournissant une vue courte et rapide de la pile de hotspot. Et la pile Java dans un instantané séparé, afin que vous puissiez analyser (ou exclure) dans un espace de mémoire Java spécifique à ce moment-là.
Tas psyounggen total 466944K, utilisé 178734K [0xffffffff45c00000, 0xffffff70800000, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffr ffffffff62400000, 0xfffffff62400000,0xfffffffff70800000) E 233472K, 0% utilisé [0xfffffffff54000000, 0xFFFFFFFF540000, 0xffffffFFFF62400000) PSOLDGEN TOTAL 1400832K, utilisé 1400831K [0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFF45BFFFFBB8,0XFFFFFFFFF45C00000) PSPERMGEN Total 262144K, utilisé 248475K [0 XFFFFFFFFFFFFED0400000, 0xFFFFFFFFFFEE0400000, 0xFFFFFFFFFFFFEF0400000) Espace des objets 262144K, 94% utilisé [0xffffffffffed0400000,0xffffffffff6a6f08,0xfffffffffee040000