Vamos explorar o conceito de *despejo de threads* e as metodologias para sua análise eficaz.
Além disso, examinaremos como essa prática auxilia na identificação de problemas e apresentaremos alguns dos analisadores disponíveis para essa finalidade.
O que é um Thread?
Um processo representa um programa de computador que é carregado na memória e está em execução. Ele pode ser executado por um processador ou um conjunto de processadores. Na memória, um processo é caracterizado por informações cruciais, como o armazenamento de variáveis, manipuladores de arquivos, contador de programa, registradores e sinais.
Internamente, um processo pode ser composto por várias unidades de execução leves, conhecidas como *threads*. Isso viabiliza o paralelismo, onde um processo é segmentado em múltiplas *threads*, resultando em um desempenho aprimorado. É importante notar que todas as *threads* de um processo compartilham o mesmo espaço de memória e são interdependentes.
Despejos de Thread: Uma Visão Geral
Enquanto um processo está ativo, podemos capturar o estado de execução de suas *threads* através dos chamados *despejos de thread*. Um *despejo de thread* é essencialmente um retrato instantâneo de todas as *threads* ativas em um dado momento durante a execução de um programa. Ele contém detalhes relevantes sobre cada *thread* e seu estado atual.
Atualmente, as aplicações modernas frequentemente envolvem um grande número de *threads*. Cada *thread* demanda recursos específicos e executa tarefas relacionadas ao processo. Isso pode otimizar o desempenho de uma aplicação, permitindo que as *threads* utilizem os núcleos de CPU disponíveis de forma eficiente.
Entretanto, essa abordagem também tem suas desvantagens. Por exemplo, *threads* concorrentes podem não se coordenar adequadamente, levando a situações de impasse. Nesse sentido, os *despejos de thread* são ferramentas indispensáveis para investigar o estado de nossas *threads* quando ocorrem anomalias.
Despejo de Thread no Contexto Java
Um *despejo de thread* em Java, ou *JVM thread dump*, é uma lista detalhada do estado de todas as *threads* que pertencem a um processo em um instante específico. Ele inclui informações sobre a pilha de cada *thread*, apresentado como um rastreamento de pilha. O formato em texto simples permite que o conteúdo seja salvo para análises posteriores. A análise de *despejos de thread* pode ser crucial para:
- Otimizar o desempenho da JVM.
- Aprimorar o desempenho da aplicação.
- Diagnosticar problemas como impasses, contenção de *threads*, etc.
Métodos para Gerar Despejos de Thread
Existem várias maneiras de obter *despejos de thread*. Algumas ferramentas baseadas em JVM podem ser executadas a partir da linha de comando (ferramentas CLI), enquanto outras podem ser encontradas no diretório `/bin` da pasta de instalação do Java (ferramentas GUI). Vamos analisar algumas delas.
#1. jStack
A ferramenta mais direta para gerar um *despejo de thread* é o `jStack`. Esta ferramenta acompanha a JVM e pode ser utilizada na linha de comando. Para isso, necessitamos do PID (Process ID) do processo para o qual desejamos gerar o *despejo*. O comando `jps` nos auxilia na obtenção do PID, como demonstrado abaixo.
jps -l
O comando `jps` lista todos os IDs de processos Java.
No Windows
C:Program FilesJavajdk1.8.0_171bin>jps -l 47172 portal 6120 sun.tools.jps.Jps C:Program FilesJavajdk1.8.0_171bin>
No 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] ~]#
Como podemos ver, obtemos uma lista de todos os processos Java em execução. A primeira coluna indica o ID da VM local e a segunda, o nome do aplicativo. Para gerar o *despejo de thread*, utilizamos o programa `jStack` com a opção `-l`, que produz uma listagem detalhada do despejo. O resultado pode ser redirecionado para um arquivo de texto.
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
O Jvisualvm é uma ferramenta GUI para solucionar problemas, monitorar e criar perfis de aplicações Java. Ela acompanha a JVM e pode ser iniciada a partir do diretório `/bin` da instalação Java. De fácil utilização, o Jvisualvm permite capturar o *despejo de thread* de um processo específico.
Para visualizar o *despejo de thread* de um processo, basta clicar com o botão direito sobre ele e selecionar a opção correspondente no menu de contexto.
#3. jcmd
O `jcmd` é um utilitário de linha de comando que também acompanha o JDK. Ele serve para enviar comandos de diagnóstico para a JVM. No entanto, ele funciona apenas na máquina local onde a aplicação Java está sendo executada. Ele pode ser utilizado para controlar gravações de voo Java, diagnosticar e solucionar problemas de aplicações JVM e Java. Usando o comando `Thread.print`, podemos obter a lista de *despejos de thread* para um processo específico, identificado por seu PID.
Segue um exemplo de como usar o `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 significa Java Mission Control, uma ferramenta GUI de código aberto que acompanha o JDK. O JMC é usado para coletar e analisar dados de aplicações Java. Ele pode ser iniciado a partir da pasta `/bin` da instalação Java.
Desenvolvedores e administradores usam essa ferramenta para obter informações detalhadas sobre o comportamento da JVM e da aplicação. Ele permite uma análise eficiente dos dados coletados pelo Java Flight Recorder. Após iniciar o JMC, uma lista de processos Java em execução na máquina local é exibida. Uma conexão remota também é possível. Para um processo específico, podemos clicar com o botão direito e escolher “Iniciar gravação de voo”, e posteriormente inspecionar os *despejos de thread* na aba “Threads”.
#5. jconsole
O `jconsole` é uma ferramenta Java Management Extension usada para monitoramento e gestão de aplicações. Ele oferece um conjunto de operações predefinidas no agente JMX que o usuário pode executar. Ele possibilita que o usuário detecte e analise o rastreamento de pilha de um programa em execução. Ele também é iniciado a partir da pasta `/bin` da instalação Java.
Usando a interface gráfica do `jconsole`, podemos inspecionar o rastreamento de pilha de cada thread ao conectar a um processo Java em execução. Na aba “Threads”, vemos o nome de todas as threads em execução. Para detectar um impasse, clicamos em “Detectar impasse” no canto inferior direito da janela. Se um impasse for detectado, ele aparecerá em uma nova aba, caso contrário, uma mensagem indicará que nenhum impasse foi encontrado.
#6. ThreadMxBean
O `ThreadMXBean` é a interface para o gerenciamento do sistema de *threads* da máquina virtual Java, pertencente ao pacote `java.lang.management`. Ele é usado principalmente para detectar *threads* que entraram em uma situação de impasse e obter informações detalhadas sobre elas.
Podemos usar essa interface para capturar programaticamente o *despejo de thread*. O método `getThreadMXBean()` de `ManagementFactory` é usado para obter uma instância da interface `ThreadMXBean`. Ele retorna o número de *threads* ativas do tipo daemon e não daemon. `ManagementFactory` é uma classe de fábrica para obter os beans gerenciados da plataforma 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 ();
}
Análise Manual de Despejos de Thread
A análise de *despejos de thread* é valiosa para identificar problemas em processos com múltiplas *threads*. Problemas como bloqueios, contenção de bloqueio e uso excessivo de CPU por *threads* específicas podem ser identificados analisando os estados de cada *thread*.
O desempenho máximo de uma aplicação pode ser alcançado ao corrigir o status de cada *thread* após uma análise detalhada do *despejo de thread*. Por exemplo, se um processo está consumindo muita CPU, podemos descobrir se alguma *thread* específica está utilizando mais recursos. Se houver tal *thread*, convertemos seu número LWP para hexadecimal. A partir do *despejo de thread*, podemos localizar a *thread* com o `nid` igual ao número hexadecimal obtido. Usando o rastreamento de pilha, podemos identificar o problema. O ID do processo da *thread* pode ser obtido usando o comando abaixo.
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
Vamos analisar o seguinte trecho de um *despejo de thread*. Para obter o *despejo de thread* do processo 26680, usamos `jstack -l 26680`.
[[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
Agora, vamos entender os elementos que podemos extrair de um *despejo de thread*. A quantidade de informação pode parecer opressiva, mas ao analisar cada parte individualmente, o processo se torna mais claro. A primeira linha indica:
2020-06-27 09:01:29
Despejo de encadeamento completo Java HotSpot(TM) 64-Bit Server VM (modo misto 25.221-b11):
O exemplo acima indica a hora em que o *despejo* foi gerado e detalhes sobre a JVM utilizada. Em seguida, temos a lista de *threads*, começando com a `ReferenceHandler`.
Analisando Threads Bloqueadas
Ao analisar os logs do *despejo de thread*, é possível identificar *threads* com o status `BLOCKED`, o que afeta o desempenho da aplicação. Ao identificar *threads* bloqueadas, podemos investigar os bloqueios que elas estão tentando adquirir. A análise do rastreamento de pilha da *thread* que está segurando o bloqueio pode ajudar a resolver o problema.
[[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 entry [0x00