Dans cet article, je vais vous apprendre comment analyser la pile de threads JVM et comment trouver la cause première du problème à partir des informations sur la pile. À mon avis, la technologie d'analyse de la pile de threads est une technologie que les ingénieurs du support produit Java EE doivent maîtriser. Les informations stockées dans la pile de threads dépassent généralement de loin votre imagination et nous pouvons faire bon usage de ces informations dans notre travail.
Mon objectif est de partager les connaissances et l'expérience que j'ai accumulées en analyse de threads au cours des douze dernières années. Ces connaissances et cette expérience ont été acquises grâce à une analyse approfondie de différentes versions de JVM et de fournisseurs de JVM de différents fournisseurs. Au cours du processus, j'ai également résumé un grand nombre de modèles de problèmes courants.
Alors, êtes-vous prêt ? Ajoutez cet article à vos favoris maintenant et je vous proposerai cette série d'articles spéciaux dans les semaines à venir. Qu'attendez-vous ? Partagez ce plan de formation sur l'analyse des fils de discussion avec vos collègues et amis.
Ça a l'air bien, je devrais certainement améliorer mes compétences en analyse de pile de threads... mais par où commencer ?
Mon conseil est de me suivre dans ce programme de formation en analyse de fils. Vous trouverez ci-dessous le contenu de la formation que nous couvrirons. En parallèle, je partagerai avec vous les cas réels que j'ai traités afin que vous puissiez apprendre et comprendre.
1) Présentation et connaissances de base des piles de threads
2) Principes de génération de piles de threads et outils associés
3) Différences dans les formats de piles de threads dans différentes JVM (Sun HotSpot, IBM JRE, Oracal JRockit)
4) Introduction et méthode d'analyse du journal de la pile de threads
5) Analyse de la pile de threads et technologies associées
6) Modèles de problèmes courants (course aux threads, blocage, blocage d'appel IO, problèmes de garbage collection/OutOfMemoryError, infini boucles, etc.)
7) Exemple d'analyse de problèmes de pile de threads
J'espère que cette série de formations pourra vous apporter une réelle aide, alors continuez à prêter attention aux mises à jour hebdomadaires des articles.
Mais que dois-je faire si j'ai des questions pendant le processus d'apprentissage ou si je ne comprends pas le contenu de l'article ?
Ne vous inquiétez pas, considérez-moi simplement comme votre mentor. Vous pouvez me consulter pour toute question concernant la pile de threads (à condition que le problème ne soit pas trop faible). N'hésitez pas à choisir l'un des moyens suivants pour me contacter :
1) Laissez un commentaire directement sous cet article (vous pouvez rester anonyme si vous êtes désolé)
2) Soumettez votre données de pile de threads au forum Root Cause Analysis
3) Envoyez-moi un email à @phcharbonneau@hotmail.com
Pouvez-vous m'aider à analyser les problèmes rencontrés dans nos produits ?
Bien sûr, si vous le souhaitez, vous pouvez m'envoyer vos données en direct par e-mail ou via le forum Root Cause Analysis. Résoudre des problèmes pratiques est le meilleur moyen d’apprendre et d’améliorer ses compétences.
J'espère vraiment que cette formation vous plaira tous. Je ferai donc de mon mieux pour vous fournir des matériaux de haute qualité et répondre à vos questions.
Avant de présenter la technologie d'analyse de la pile de threads et le modèle de problème, je dois d'abord vous expliquer le contenu de base. Ainsi, dans cet article, je couvrirai d'abord le contenu le plus basique, afin que chacun puisse mieux comprendre l'interaction entre la JVM, le middleware et les conteneurs Java EE.
Présentation de la VM Java
La machine virtuelle Java est la base de la plateforme Java EE. C'est là que les middlewares et les applications sont déployés et exécutés.
JVM fournit les éléments suivants aux logiciels middleware et à vos programmes Java/Java EE :
– (sous forme binaire) Environnement d'exécution du programme Java/Java EE
– Certains programmes Caractéristiques et outils (Infrastructure IO, structures de données, gestion des threads, sécurité, surveillance, etc.)
– Allocation et gestion dynamique de la mémoire avec garbage collection
Votre JVM peut résider sur plusieurs Au-dessus du système d'exploitation (Solaris, AIX, Windows, etc.), et en fonction de la configuration de votre serveur physique, vous pouvez installer 1 à plusieurs processus JVM sur chaque serveur physique/virtuel.
JVM et interaction entre middleware
Ce qui suit La figure montre le modèle d'interaction de haut niveau entre la JVM, le middleware et les applications.
La figure montre quelques interactions simples et typiques entre la JVM, le middleware et le logiciel d'application. Comme vous pouvez le constater, l'allocation des threads pour les applications Java EE standard se fait entre le noyau middleware et la JVM. (Bien sûr, il existe des exceptions. Les applications peuvent appeler directement l'API pour créer des threads. Ce n'est pas courant, et des précautions particulières doivent être prises lors de l'utilisation)
Par ailleurs, veuillez noter que certains threads sont créés en interne par la JVM Pour la gestion, un exemple typique est le thread de garbage collection, qui est utilisé en interne par la JVM pour effectuer un traitement parallèle de garbage collection.
Étant donné que la plupart des allocations de threads sont effectuées par le conteneur Java EE, il est important que vous puissiez comprendre et reconnaître les traces de la pile de threads et les identifier à partir des données de la pile de threads. Cela vous permet de savoir rapidement de quel type. de la requête que le conteneur Java EE exécute.
Du point de vue de l'analyse d'une pile de thread dump, vous pourrez comprendre les différences entre les pools de threads découverts par la JVM et identifier le type de requête.
La dernière section vous fournira un aperçu de ce qu'est la pile de threads JVM pour HotSop VM, ainsi que des différents threads que vous rencontrerez. Les détails du formulaire de pile de threads IBM VM seront fournis dans la section 4. vous.
Veuillez noter que vous pouvez obtenir un exemple de pile de threads pour cet article sur le forum d'analyse des causes profondes.
Pile de threads JVM - Qu'est-ce que c'est ?
La JVM la pile de threads est un instantané à un instant donné qui vous fournit une liste complète de tous les threads Java qui ont été créés.
Chaque thread Java découvert vous donnera les informations suivantes :
– La nom du thread ; il est souvent utilisé par les fabricants de middleware pour identifier les threads. Il porte généralement également le nom et l'état du pool de threads (en cours d'exécution, bloqué, etc.)
– Type et priorité du thread, par exemple : daemon prio=3 ** Les programmes middleware créent généralement leurs threads sous forme de démons en arrière-plan, ce qui signifie que ces threads s'exécutent en arrière-plan ; ils fournissent des services à leurs utilisateurs, par exemple : à votre application Java EE **
– ID de thread Java, par exemple : tid=0x000000011e52a800 ** Il s'agit de l'ID de thread Java obtenu via java.lang.Thread.getId(), qui est souvent utilisé comme un long Shaping 1..n à croissance automatique** implémente
– ID de thread natif, par exemple : nid=0x251c**, la raison pour laquelle la clé est parce que l'ID de thread natif vous permet d'obtenir des informations telles que du point de vue du système d'exploitation Informations sur lesquelles le thread utilise la majeure partie du temps CPU de votre JVM. **
– État et détails du thread Java, par exemple : en attente de l'entrée du moniteur [0xfffffffea5afb000] java.lang.Thread .State : BLOCKED (sur le moniteur d'objet). )
** Vous pouvez rapidement comprendre l'état du thread et les raisons possibles du blocage actuel**
– Trace de la pile de threads Java ; voici ce que vous pouvez faire à partir de la pile de threads jusqu'à présent. Les données les plus importantes ; trouvé en % d’information.
– Décomposition de la mémoire du tas Java ; à partir de la version 1.6 de HotSpot VM, vous pouvez voir l'utilisation de la mémoire de HotSpot à la fin de la pile de threads, comme la mémoire du tas de Java (YoungGen, OldGen) et l'espace PermGen. Ces informations sont utiles lors de l’analyse des problèmes causés par des GC fréquents. Vous pouvez utiliser des données ou des modèles de thread connus pour effectuer une localisation rapide.
Heap PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000) eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000) from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000) to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000) PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000) object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000) PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000) object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)
Grand démantèlement des informations sur la pile de threads
Afin de vous donner une meilleure compréhension, nous vous fournissons l'image suivante, dans laquelle les informations sur la pile de threads sur HotSpot VM sont détaillées le démontage du pool de threads a été effectué, comme le montre la figure suivante :
Comme on peut le voir sur la figure ci-dessus, la pile de threads est composée de plusieurs parties différentes. Ces informations sont toutes importantes pour l'analyse des problèmes, mais différentes parties seront utilisées pour analyser différents modèles de problèmes (les modèles de problèmes seront simulés et démontrés dans des articles ultérieurs.)
Maintenant, à travers cet exemple d'analyse, permettez-moi expliquez en détail les différents composants des informations de la pile de threads sur HoteSpot :
# Full thread dump标示符
"Full thread dump" est un mot-clé unique au monde, vous pouvez le trouver dans le journal de sortie du informations sur la pile de threads du middleware et de la version autonome de Java (par exemple, utilisez : kill -3
Dump complet des threads Java HotSpot(TM) 64 bits serveur VM (mode mixte 20.0-b11) :
# Threads dans le middleware Java EE, les logiciels d'application tiers et personnalisés
Cette partie est la partie centrale de toute la pile de threads, et c'est aussi la partie qui prend généralement le plus de temps d'analyse. Le nombre de threads dans la pile dépend du middleware que vous utilisez, des bibliothèques tierces (qui peuvent avoir des threads indépendants) et de votre application (si vous créez des threads personnalisés, 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, un pool de threads autogéré identifié de manière unique par "'weblogic.kernel.Default (self-tuning)" sera utilisé
"[STANDBY] ExecuteThread: '414' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xffffffff27d44de0> (a weblogic.work.ExecuteThread) at java.lang.Object.wait(Object.java:485) at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160) - locked <0xffffffff27d44de0> (a weblogic.work.ExecuteThread) at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
# HotSpot Thread VM
Il s'agit d'un thread interne géré par Hotspot VM et utilisé pour effectuer des opérations natives internes. En général, vous n'avez pas besoin de trop vous inquiéter à ce sujet, sauf si vous constatez une utilisation élevée du processeur (via les piles de threads associées et les ID de thread prstat ou natifs).
"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition
# HotSpot GC Threads
Lors de l'utilisation de HotSpot pour du GC parallèle (courant de nos jours dans les environnements utilisant plusieurs cœurs physiques), la VM HotSpot créée par défaut ou chaque JVM gère un thread GC avec une identité spécifique. Ces Threads GC permettent à la VM d'effectuer son travail. nettoyage périodique du GC en parallèle, ce qui entraînera une réduction globale du temps GC en même temps, le coût est une augmentation du temps d'utilisation du processeur.
"GC task thread#0 (ParallelGC)" prio=3 tid=0x0000000100120000 nid=0x3 runnable "GC task thread#1 (ParallelGC)" prio=3 tid=0x0000000100131000 nid=0x4 runnable ………………………………………………………………………………………………………………………………………………………………
这事非常关键的数据,因为当你遇到跟GC有关的问题,诸如过度GC、内存泄露等问题是,你将可以利用这些线程的原生Id值关联的操作系统或者Java线程,进而发现任何对CPI时间的高占用. 未来的文章你将会了解到如何识别并诊断这样的问题.
# JNI 全局引用计数
JNI (Java 本地接口)的全局引用就是从本地代码到由Java垃圾收集器管理的Java对象的基本的对象引用. 它的角色就是阻止对仍然在被本地代码使用,但是技术上已经不是Java代码中的“活动的”引用了的对象的垃圾收集.
同时为了侦测JNI相关的泄露而留意JNI引用也很重要. 如果你的程序直接使用了JNI,或者像监听器这样的第三方工具,就容易造成本地的内存泄露.
JNI global references: 1925
# Java 堆栈使用视图
这些数据被添加回了 JDK 1 .6 ,向你提供有关Hotspot堆栈的一个简短而快速的视图. 我发现它在当我处理带有过高CPU占用的GC相关的问题时非常有用,你可以在一个单独的快照中同时看到线程堆栈以及Java堆的信息,让你当时就可以在一个特定的Java堆内存空间中解析(或者排除)出任何的关键点. 你如在我们的示例线程堆栈中所见,Java 的堆 OldGen 超出了最大值!
Heap PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000) eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000) from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000) to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000) PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000) object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000) PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000) object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee040000
更多Analyse JVM approfondie de la pile de threads Java相关文章请关注PHP中文网!