Comment faire thread dump java
Java discussion Décharges
Dans cet article, nous allons essayer de comprendre Java et discussion Décharges comment ils peuvent être des outils très puissants pour comprendre et résoudre rapidement les problèmes communs. Cet article est divisé en 2 parties. La première partie se concentre sur des sujets fondamentaux suivants- Brève introduction aux threads Java
- Comprendre ce que sont les décharges de fil
- Format des décharges de fil
- Comment prendre des décharges de fil
Dans la deuxième partie, nous allons apprendre à disséquer et interpréter les décharges de fil par
- Comprendre les états de fil
- Les meilleures pratiques autour de l'analyse des décharges
- L'analyse de quelques conditions de course
- Ressources
Tout au long de cet article, les décharges de fil indiqués sont des scénarios de la vie réelle. Cependant, dans l'intérêt de l'espace que des extraits ont été représentés. Nous espérons que les concepts fondamentaux peuvent être facilement comprises encore et faciles à appliquer à votre situation.
Processus et threads sont des éléments de base pour la programmation concurrente.
Les threads sont parfois appelés processus légers. Les deux processus et les threads offrent un environnement d'exécution, mais la création d'un nouveau thread nécessite moins de ressources que la création d'un nouveau processus.
Threads exister dans un processus - chaque processus a au moins un. Threads partagent les ressources du processus, y compris la mémoire et les fichiers ouverts. Cela fait, une communication efficace, mais potentiellement problématique. l'exécution multithread est une caractéristique essentielle de la plate-forme Java. Chaque application a au moins un fil - ou plusieurs, si l'on compte threads « système » qui font des choses comme la gestion de la mémoire et de traitement du signal. Mais du point de programmeur d'application de vue, vous commencez avec un seul fil, appelé le thread principal. Ce fil a la capacité de créer des threads supplémentaires, comme nous allons le démontrer dans la section suivante. La plupart des implémentations de la machine virtuelle Java fonctionnent comme un processus unique.
Le reste de l'article suppose que vous avez des connaissances de base de la programmation avec des fils sur java. Si vous souhaitez rafraîchir vos connaissances, nous recommandons fortement le chapitre Concurrency du Sun Java Tutorial. Vous pouvez aussi regarder plusieurs autres ressources en ligne.
Quels sont les décharges de fil
Entendons-nous des décharges de fil en regardant une décharge de fil.
fil complet vidage Java HotSpot (TM) VM Client (mode mixte 1.5.0_04-b05, partage):
"DestroyJavaVM" prio = 5 tid = 0x00036218 = 0xd68 attente JNV condition [0x00000000..0x0007fae8]
"Discussion-1" prio = 5 tid = 0x00ab8e68 = 0xe14 attente JNV condition [0x02d0f000..0x02d0fb68]
à java.lang.Thread.sleep (Méthode natif)
à org.tw.testyard.thread.Consumer.run (Consumer.java:18)
à java.lang.Thread.run (Source inconnue)
"Discussion-0" prio = 5 tid = 0x00aa3ab8 = 0x1530 attente JNV condition [0x02ccf000..0x02ccfbe8]
à java.lang.Thread.sleep (Méthode natif)
à org.tw.testyard.thread.Producer.run (Producer.java:24)
à java.lang.Thread.run (Source inconnue)
démon "Détecteur de mémoire faible" prio = 5 tid = 0x00a6e950 = 0x1698 JNV runnable [0x00000000..0x00000000]
démon "CompilerThread0" prio = 10 tid = 0x00a6d658 = 0x5b8 attente JNV à la condition [de 0x00000000..0x02c0fa4c]
démon "Signal Dispatcher" prio = 10 tid = 0x00a6c7c0 = 0x15e0 attente JNV condition [0x00000000..0x00000000]
daemon "Finalizer" prio = 9 tid = 0x0003fb00 nid = de 0x598 à Object.wait () [0x02b8f000..0x02b8fa68]
à java.lang.Object.wait (Méthode natif)
- attendre sur <0x22a80840> (Un java.lang.ref.ReferenceQueue $ Lock)
à java.lang.ref.ReferenceQueue.remove (Source inconnue)
- fermé à clef <0x22a80840> (Un java.lang.ref.ReferenceQueue $ Lock)
à java.lang.ref.ReferenceQueue.remove (Source inconnue)
à java.lang.ref.Finalizer $ FinalizerThread.run (Source inconnue)
démon "gestionnaire de référence" prio = 10 tid = 0x00a47aa0 = 0x1538 dans JNV Object.wait () [0x02b4f000..0x02b4fae8]
à java.lang.Object.wait (Méthode natif)
- attendre sur <0x22a80750> (Un java.lang.ref.Reference $ Lock)
à java.lang.Object.wait (Source inconnue)
à java.lang.ref.Reference $ ReferenceHandler.run (Source inconnue)
- fermé à clef <0x22a80750> (Un java.lang.ref.Reference $ Lock)
"Discussion VM" prio = 10 tid = 0x00a67ce8 = 0xc78 JNV runnable
"VM périodique Tâche Thread" prio = 10 tid = 0x00a6fc90 = 0x830 attente JNV condition
Comme son nom l'indique thread dump est une décharge de tous les fils dans une machine virtuelle Java. Il contient l'état d'exécution en cours à la fois de l'application et les fils spécifiques JVM. L'extrait ci-dessus de vidage de fil montre deux fils d'application [Discussion-0 et thread-1] et les fils spécifiques JVM tels que "Signal Dispatcher", "Finalizer", etc. Aux fins du présent article, nous allons nous concentrer uniquement sur les threads de l'application.
- Pour obtenir une vue globale de ce qui se passe dans l'application à ce moment précis
- Pour exposer les problèmes flagrants, tels que
- des portions de code qui semblent être presque toujours invoqué
- des portions de code lorsque la demande semble être accroché
- problèmes de verrouillage et de synchronisation du fil dans une application
- des portions de code qui semblent être presque toujours invoqué
- De plus, ils sont très précieux dans des environnements de production où les outils de profilage sophistiqués ne peuvent pas être facilement attachés
Format des décharges de fil
Le format de vidage de fil a changé avec les versions JSE. Sun ou tout autre fournisseurs informent les utilisateurs que le format va changer entre les versions. Cependant une chose qui n'a pas changé est le niveau de l'information contenue dans une décharge de fil. Comme mentionné ci-dessus décharges de fil est un instantané de l'état JVM liste de tous les threads d'application et au niveau du système et de surveiller les états.
fil complet vidage Java HotSpot (TM) VM Client (mode mixte 1.5.0_04-b05, partage):
"Fil-1" prio = 5 tid = 0x00a995d0 nid = 0x1300 dans Object.wait () [0x02d0f000..0x02d0fb68]
à java.lang.Object.wait (Méthode natif)
- attendre sur <0x22aaa8d0> (A org.tw.testyard.thread.Drop)
à java.lang.Object.wait (Source inconnue)
à org.tw.testyard.thread.Drop.take (Drop.java:14)
- fermé à clef <0x22aaa8d0> (A org.tw.testyard.thread.Drop)
à org.tw.testyard.thread.Consumer.run (Consumer.java:15)
à java.lang.Thread.run (Source inconnue)
"Discussion-0" prio = 5 tid = 0x00a88440 = 0x6a4 attente JNV condition [0x02ccf000..0x02ccfbe8]
à java.lang.Thread.sleep (Méthode natif)
à org.tw.testyard.thread.Producer.run (Producer.java:24)
à java.lang.Thread.run (Source inconnue)
Dans l'extrait de vidage de fil ci-dessus, vous pouvez observer les points suivants
- Le vidage de fil commence par « vidage de fil complet », suivi d'une liste de threads en cours d'exécution.
- Il y a 2 fils d'application appelés thread-1 et fil-0. Ce sont les noms par défaut qui la machine virtuelle Java remis aux fils.
- « Discussion-1 » est en attente d'une notification après appelé Object.wait () sur l'objet Drop.
- De même, « thread-0 » dort sur une condition après avoir appelé Thread.sleep
- A cet instant particulier, il n'y a pas de fils dans l'état inexécutable et par conséquent l'application ne fait pas un travail réel.
Bien que les décharges fil énumère également l'état des fils du système, nous n'allons pas regarder plus profondément dans les discussions du système.
Comment prendre des décharges de fil
décharges de discussion peuvent être générés par les utilisateurs, ainsi que le système dans des situations inhabituelles. Les utilisateurs peuvent générer des décharges de fil en envoyant explicitement un signal à la machine virtuelle Java ou programatically en appelant java.lang.Exception.printStackTrace (). Appel de la méthode printStackTrace () ne fera que provoquer la trace de pile du thread courant à imprimer.
Bien que très rare la machine virtuelle Java peut également générer un vidage de fil lorsqu'un thread provoque la machine virtuelle Java crash. La quantité d'informations qui obtient de nouveau enregistré est spécifique de mise en œuvre. En règle générale, vous trouverez des informations sur le fil qui a causé la machine virtuelle Java crash.
Dans cette section, nous avons eu un coup d'oeil sur les discussions, les formats de vidage de fil et la façon de prendre des décharges de fil. Le plaisir ne fait que commencer. Dans la section suivante, nous allons comprendre l'état de fil et la façon d'interpréter les décharges de fil. Cliquez ici pour accéder à la partie suivante