2022-11-26 09:40 Temps de lecture : 28 min
Technologie

Qu'est-ce que le Thread Dump et comment les analyser ?

Explorons le concept de vidage de thread et sa méthode d'analyse.

Nous allons également examiner comment cela contribue à l'identification des problèmes et certains outils d'analyse que vous pouvez utiliser.

Qu'est-ce qu'un thread ?

Un processus est un programme informatique qui est chargé en mémoire vive (RAM) et qui est en cours d'exécution. Il peut être exécuté par un ou plusieurs processeurs. Un processus est décrit en mémoire à l'aide d'informations importantes telles que le stockage des variables, les descripteurs de fichiers, le pointeur d'instruction, les registres et les signaux, entre autres.

Un processus peut être composé de plusieurs unités d'exécution légères, appelées threads. Cela permet d'obtenir un fonctionnement en parallèle, où un processus est divisé en plusieurs threads, améliorant ainsi les performances. Tous les threads d'un même processus partagent le même espace mémoire et sont donc interdépendants.

Vider les threads

Quand un processus est en cours d'exécution, nous pouvons observer l'état actuel des threads qui le composent grâce aux vidages de thread. Un vidage de thread est une capture instantanée de tous les threads actifs à un moment précis de l'exécution d'un programme. Il contient toutes les informations utiles sur chaque thread et son état.

De nos jours, une application moderne utilise de nombreux threads. Chaque thread nécessite des ressources spécifiques et effectue des actions en lien avec le processus. L'utilisation de plusieurs threads peut optimiser les performances, car ils peuvent exploiter les cœurs de processeur disponibles.

Cependant, il y a des inconvénients. Par exemple, il arrive que plusieurs threads ne se coordonnent pas bien et cela peut provoquer des situations de blocage. Ainsi, si quelque chose ne fonctionne pas, nous pouvons utiliser les vidages de thread pour examiner l'état de nos threads.

Vidage de thread en Java

Un vidage de thread JVM est une liste de l'état de tous les threads actifs dans un processus à un instant donné. Il contient des informations sur la pile d'exécution du thread, présentée sous forme de trace de pile. Étant donné que ces données sont au format texte brut, elles peuvent être conservées pour une consultation ultérieure. L'analyse des vidages de thread peut faciliter :

  • L'optimisation des performances de la JVM
  • L'amélioration des performances des applications
  • Le diagnostic des problèmes comme les blocages ou les conflits entre threads

Génération de vidages de threads

Il existe plusieurs méthodes pour produire des vidages de thread. Voici quelques outils basés sur la JVM, exécutables en ligne de commande ou depuis le répertoire "/bin" du dossier d'installation Java (pour les outils avec une interface graphique).

Examinons-les.

#1. jStack

La méthode la plus simple pour générer un vidage de thread est d'utiliser jStack. Cet utilitaire est inclus dans la JVM et s'utilise en ligne de commande. Il est nécessaire de connaître l'ID du processus (PID) pour lequel nous souhaitons créer un vidage de thread. Pour obtenir ce PID, la commande jps peut être utilisée comme illustré ci-dessous.

jps-l

jps affiche la liste de tous les identifiants de processus Java.

Sous Windows

C:Program FilesJavajdk1.8.0_171bin>jps -l
47172 portal
6120 sun.tools.jps.Jps
C:Program FilesJavajdk1.8.0_171bin>

Sous Linux

[[email protected] ~]# jps -l
1088 /opt/keycloak/jboss-modules.jar
26680 /var/lib/jenkins/workspace/kyc/kyc/target/kyc-1.0.jar
7193 jdk.jcmd/sun.tools.jps.Jps
2058 /usr/share/jenkins/jenkins.war
11933 /var/lib/jenkins/workspace/admin-portal/target/portal-1.0.jar
[[email protected] ~]#

Comme nous le voyons, nous obtenons une liste de tous les processus Java en cours. Cette liste comprend l'identifiant de la machine virtuelle locale pour chaque processus Java en cours d'exécution, ainsi que le nom de l'application. Pour générer le vidage de thread, nous utilisons ensuite le programme jStack avec l'option –l, qui produit une sortie détaillée du vidage. La sortie peut être redirigée vers un fichier texte.

jstack -l 26680

[[email protected] ~]# jstack -l 26680
2020-06-27 06:04:53
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):

"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"logback-8" #2316 daemon prio=5 os_prio=0 tid=0x00007f07e0033000 nid=0x4792 waiting on condition [0x00007f07baff8000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006ca9a1fc0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"logback-7" #2315 daemon prio=5 os_prio=0 tid=0x00007f07e0251800 nid=0x4791 waiting on condition [0x00007f07bb0f9000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006ca9a1fc0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

#2. jvisualvm

Jvisualvm est un outil graphique qui facilite le débogage, la surveillance et le profilage des applications Java. Il est également fourni avec la JVM et peut être lancé depuis le répertoire "/bin" de l'installation Java. Il est très convivial et intuitif. Il permet notamment de générer des vidages de thread pour un processus spécifique.

Pour visualiser le vidage de thread d'un processus en particulier, il suffit de faire un clic droit sur le processus concerné et de sélectionner "Thread Dump" dans le menu contextuel.

#3. jcmd

JCMD est un utilitaire en ligne de commande, inclus dans le JDK. Il est conçu pour envoyer des commandes de diagnostic à la JVM.

Il ne fonctionne cependant que sur la machine locale où l'application Java est exécutée. Il peut être utilisé pour contrôler les enregistrements de vol Java, pour diagnostiquer et résoudre des problèmes dans les applications JVM et Java. La commande "Thread.print" de jcmd permet d'obtenir une liste de vidages de thread pour un processus spécifique, identifié par son PID.

Voici un exemple d'utilisation de jcmd.

jcmd 28036 Thread.print

C:Program FilesJavajdk1.8.0_171bin>jcmd 28036 Thread.print
28036:
2020-06-27 21:20:02
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):

"Bundle File Closer" #14 daemon prio=5 os_prio=0 tid=0x0000000021d1c000 nid=0x1d4c in Object.wait() [0x00000000244ef000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Unknown Source)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:403)
        - locked <0x000000076f380a88> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:339)

"Active Thread: Equinox Container: 0b6cc851-96cd-46de-a92b-253c7f7671b9" #12 prio=5 os_prio=0 tid=0x0000000022e61800 nid=0xbff4 waiting on condition [0x00000000243ee000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000076f388188> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000021a7b000 nid=0x2184 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x00000000219f5000 nid=0x1300 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x00000000219e0000 nid=0x48f4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x00000000219df000 nid=0xb314 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00000000219db800 nid=0x2260 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00000000219d9000 nid=0x125c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00000000219d8000 nid=0x834 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001faf3000 nid=0x36c0 in Object.wait() [0x0000000021eae000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        - locked <0x000000076f390180> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(Unknown Source)
        at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000005806000 nid=0x13c0 in Object.wait() [0x00000000219af000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076f398178> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Unknown Source)
        at java.lang.ref.Reference.tryHandlePending(Unknown Source)
        - locked <0x000000076f398178> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)

"main" #1 prio=5 os_prio=0 tid=0x000000000570e800 nid=0xbf8 runnable [0x0000000000fec000]
   java.lang.Thread.State: RUNNABLE
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:307)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getZipFile(ZipBundleFile.java:136)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.lockOpen(ZipBundleFile.java:83)
        at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getEntry(ZipBundleFile.java:290)
        at org.eclipse.equinox.weaving.hooks.WeavingBundleFile.getEntry(WeavingBundleFile.java:65)
        at org.eclipse.osgi.storage.bundlefile.BundleFileWrapper.getEntry(BundleFileWrapper.java:55)
        at org.eclipse.osgi.storage.BundleInfo$Generation.getRawHeaders(BundleInfo.java:130)
        - locked <0x000000076f85e348> (a java.lang.Object)
        at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:599)
        at org.eclipse.osgi.storage.BundleInfo$CachedManifest.get(BundleInfo.java:1)
        at org.eclipse.equinox.weaving.hooks.SupplementerRegistry.addSupplementer(SupplementerRegistry.java:172)
        at org.eclipse.equinox.weaving.hooks.WeavingHook.initialize(WeavingHook.java:138)
        at org.eclipse.equinox.weaving.hooks.WeavingHook.start(WeavingHook.java:208)
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startActivator(FrameworkExtensionInstaller.java:261)
        at org.eclipse.osgi.storage.FrameworkExtensionInstaller.startExtensionActivators(FrameworkExtensionInstaller.java:198)
        at org.eclipse.osgi.internal.framework.SystemBundleActivator.start(SystemBundleActivator.java:112)
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:815)
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:808)
        at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:765)
        at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.initWorker(EquinoxBundle.java:190)
        at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:99)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:272)
        at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:257)
        at org.eclipse.osgi.launch.Equinox.init(Equinox.java:171)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:316)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:251)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:661)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1476)

"VM Thread" os_prio=2 tid=0x000000001fae8800 nid=0x32cc runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000005727800 nid=0x3264 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000005729000 nid=0xbdf4 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000572a800 nid=0xae6c runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000572d000 nid=0x588 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x000000000572f000 nid=0xac0 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000005730800 nid=0x380 runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000005733800 nid=0x216c runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000005734800 nid=0xb930 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x0000000021a8d000 nid=0x2dcc waiting on condition

JNI global references: 14


C:Program FilesJavajdk1.8.0_171bin>

#4. JMC

JMC, abréviation de Java Mission Control, est un outil graphique open source inclus dans le JDK, qui permet de collecter et d'analyser les données d'une application Java.

Il peut être lancé depuis le dossier "/bin" de l'installation Java. Il est utilisé par les administrateurs et les développeurs Java pour obtenir des informations détaillées sur le comportement de la JVM et de l'application. Il permet une analyse fine des données recueillies par Java Flight Recorder.

Lorsque JMC est lancé, la liste des processus Java en cours d'exécution sur la machine locale est visible. Une connexion à distance est également possible. Il suffit de faire un clic droit sur un processus, de choisir "Démarrer l'enregistrement de vol", puis de consulter les vidages de thread dans l'onglet Threads.

#5. jconsole

jconsole est un outil d'extension de gestion Java (JMX) utilisé pour la gestion et la surveillance des applications.

Il intègre également un ensemble d'opérations prédéfinies que l'utilisateur peut effectuer sur l'agent JMX. Il permet de suivre et d'analyser la trace de pile d'un programme en temps réel. Il peut être lancé depuis le dossier "/bin" de l'installation Java.

L'outil graphique jconsole permet d'examiner la trace de pile de chaque thread après s'être connecté à un processus Java en cours d'exécution. L'onglet "Threads" affiche le nom de tous les threads actifs. Pour identifier un blocage, il suffit de cliquer sur le bouton "Détecter un blocage" en bas à droite de la fenêtre. S'il y a un blocage, il apparaîtra dans un nouvel onglet, sinon un message "Aucun blocage détecté" sera affiché.

#6. ThreadMxBean

ThreadMXBean est l'interface de gestion du système de threads de la machine virtuelle Java, et fait partie du package java.lang.management. Elle est principalement utilisée pour détecter les threads impliqués dans une situation de blocage et pour obtenir des informations sur ces threads.

L'interface ThreadMxBean permet de capturer un vidage de thread par programmation. La méthode "getThreadMXBean()" de la classe "ManagementFactory" est utilisée pour obtenir une instance de l'interface ThreadMXBean. Elle fournit le nombre de threads en direct, qu'ils soient démons ou non. ManagementFactory est une classe utilitaire permettant d'obtenir les beans gérés pour la plateforme Java.

private static String getThreadDump (boolean lockMonitors, boolean lockSynchronizers) {
    StringBuffer threadDump = new StringBuffer (System.lineSeparator ());
    ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean ();
    for (ThreadInfo threadInfo : threadMXBean.dumpAllThreads (lockMonitors, lockSynchronizers)) {
        threadDump.append (threadInfo.toString ());
    }
    return threadDump.toString ();
}

Analyse manuelle des vidages de thread

L'analyse des vidages de thread est essentielle pour diagnostiquer les problèmes dans les processus multithread. Des problèmes tels que les blocages, les conflits de verrouillage et l'utilisation excessive du processeur par certains threads peuvent être résolus en examinant l'état des vidages de threads individuels.

En corrigeant l'état de chaque thread après avoir analysé le vidage, le débit maximal de l'application peut être atteint.

Par exemple, si un processus consomme beaucoup de ressources CPU, il est possible de déterminer quel thread utilise le plus de CPU. S'il y a un tel thread, son numéro LWP est converti en une valeur hexadécimale. Ensuite, dans le vidage de thread, on peut trouver le thread dont l'identifiant "nid" correspond à cette valeur hexadécimale. En utilisant la trace de pile de ce thread, le problème peut être identifié. Pour connaître l'ID de processus du thread, la commande ci-dessous peut être utilisée.

ps -mo pid,lwp,stime,time,cpu -C java

[[email protected] ~]# ps -mo pid,lwp,stime,time,cpu -C java
       PID        LWP         STIME           TIME              %CPU
26680               -         Dec07          00:02:02           99.5
         -       10039        Dec07          00:00:00           0.1
         -       10040        Dec07          00:00:00           95.5

Examinons un extrait de vidage de thread. Pour obtenir un vidage de thread pour le processus 26680, la commande "jstack -l 26680" est utilisée.

[[email protected] ~]# jstack -l 26680
2020-06-27 09:01:29
<strong>Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mixed mode):</strong>

"Attach Listener" #16287 daemon prio=9 os_prio=0 tid=0x00007f0814001800 nid=0x4ff2 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

.
.
.
.
.
.
.
"<strong>Reference Handler</strong>" #2 daemon prio=10 os_prio=0 tid=0x00007f085814a000 nid=0x6840 in Object.wait() [0x00007f083b2f1000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000006c790fbd0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=0 tid=0x00007f0858140800 nid=0x683f runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f0858021000 nid=0x683b runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f0858022800 nid=0x683c runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f0858024800 nid=0x683d runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f0858026000 nid=0x683e runnable

"VM Periodic Task Thread" os_prio=0 tid=0x00007f08581a0000 nid=0x6847 waiting on condition

JNI global references: 1553

Voyons ce que nous pouvons examiner dans les vidages de thread. Le volume de contenu peut paraître intimidant, mais en y allant étape par étape, cela devient assez facile à comprendre. Examinons la première ligne :

2020-06-27 09:01:29
Vidage complet du thread Java HotSpot(TM) 64-Bit Server VM (25.221-b11 mode mixte) :

Cette ligne indique l'heure de création du vidage, ainsi que des informations sur la JVM utilisée. Ensuite, la liste des threads est affichée. Le premier thread de la liste est "ReferenceHandler".

Analyse des threads bloqués

Si nous analysons les journaux de vidage de thread suivants, nous pouvons constater qu'ils indiquent des threads à l'état "BLOCKED", ce qui ralentit considérablement les performances de l'application. Par conséquent, en trouvant ces threads "BLOCKED", nous pouvons tenter de déterminer quels sont les verrous que ces threads essaient d'acquérir. En analysant la trace de pile du thread qui détient le verrou, le problème peut être résolu.

[[email protected] ~]# jstack -l 26680
.
.
.
.
" DB-Processor-13" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor entry [0x000000000825f000]
java.lang.Thread.State: <strong>BLOCKED</strong> (on object monitor)
                at beans.ConnectionPool.getConnection(ConnectionPool.java:102)
                - waiting to lock <0xe0375410> (a beans.ConnectionPool)
                at beans.cus.ServiceCnt.getTodayCount(ServiceCnt.java:111)
                at beans.cus.ServiceCnt.insertCount(ServiceCnt.java:43)
"DB-Processor-14" daemon prio=5 tid=0x003edf98 nid=0xca waiting for monitor
Auteur
Camille Moreau
France

Rédacteur tech, guides pratiques et astuces numériques.

Articles similaires
2026-05-15
Découvrez la montre connectée légère HUAWEI WATCH FIT 5 Pro, votre alliée au quotidien  
Dans un monde où l'innovation ne cesse d'évoluer, la HUAWEI WATCH FIT 5 Pro se présente comme une option incontournable pour les amateurs d…
2026-05-05
Énergie solaire en Europe : comment bien préparer une installation photovoltaïque professionnelle ?
L’énergie solaire n’est plus seulement une solution réservée aux passionnés d’écologie ou aux grands projets industriels. Elle devient, pro…
2026-03-31
Comment économiser sur un vélo électrique : conseils pratiques pour payer moins cher en Europe
Acheter un vélo électrique représente souvent un investissement important. Entre le prix du modèle, les accessoires, la livraison et l’entr…
2026-03-11
Optimisez vos performances : Pourquoi la huawei watch gt runner est l'alliée incontournable des marathoniens en 2026 ? 
Si vous avez déjà pris le départ du Marathon de Paris ou couru le long des quais de Bordeaux, vous savez que chaque détail compte dès que l…
Article précédent
Correction de l'erreur de hachage d'image non valide de l'état de Google Chrome
Article suivant
12 façons de réparer la lampe de poche iPhone qui ne fonctionne pas