Analisador de thread dump Java — online, grátis e automático

Um analisador de thread dump elimina a parte mecânica do diagnóstico: em vez de ler centenas de pilhas à mão procurando o lock disputado ou a thread travada, você envia o arquivo e recebe os problemas já identificados, com severidade e causa raiz. Quando a aplicação está lenta em produção e o incidente está aberto, essa diferença se mede em minutos — não em horas.

O analisador do ThreadMine lê dumps de HotSpot, OpenJ9, Azul Zing e GraalVM sem que você precise dizer qual é o formato, roda 15 detectores sobre o conteúdo normalizado e devolve um relatório com health score, cards de problema e sugestões priorizadas. Online, grátis e sem cadastro para começar.

Como funciona o analisador

São três passos, do arquivo bruto ao diagnóstico:

1. Envie o dump. Abra a página inicial, cole o texto do dump ou faça upload do arquivo — sem cadastro.
2. O parser identifica a JVM automaticamente. Pelo cabeçalho e pela estrutura, o analisador reconhece se o dump veio de HotSpot, OpenJ9, Zing ou GraalVM e normaliza tudo para um modelo único.
3. Receba o relatório. Health score de A a F, lista de problemas detectados com severidade, threads envolvidas e causa raiz sugerida para cada um.

O que o analisador detecta

Entre os detectores que rodam em cada análise, os mais procurados:

• Deadlock — ciclos de lock entre threads, incluindo os já declarados pela JVM na seção Found one Java-level deadlock.
• Pool exhaustion — todas as threads de um pool (Tomcat, executor, conexões) ocupadas ao mesmo tempo, com a fila crescendo.
• CPU spike — agrupamento de threads RUNNABLE em métodos quentes: laços infinitos, regex catastrófica, serialização de objetos enormes.
• Thread leak — threads fora de pool que só aumentam, tipicamenteExecutorService nunca encerrado.
• Lock contention — muitas threads BLOCKED disputando o mesmo monitor, com identificação de quem detém o lock.
• Pinning de virtual threads — virtual threads (Loom) presas ao carrier thread por blocos synchronized ou código nativo.

Formatos de cada JVM

Cada implementação da JVM emite o dump em um formato próprio — e o analisador aceita os quatro sem configuração, detectando o formato pelo cabeçalho e pela estrutura. Vale conhecer as diferenças para saber o que esperar do arquivo.

HotSpot (OpenJDK, Oracle JDK)

É o formato mais comum. Começa com o cabeçalho Full thread dump OpenJDK 64-Bit Server VM, seguido das threads e, no fim, seção opcionalJNI global references. Quando há deadlock, aparece a seção Found one Java-level deadlock após as threads.

OpenJ9 (Eclipse / IBM)

Mais verboso. Emite arquivos no formato javacore.txtcom seções nomeadas (THREADS, CLASSES, MEMINFO, LOCKS). É útil porque já inclui diagnóstico de memória junto. Tipicamente disparado por sinal ou pela ferramentajdmpview.

Azul Zing / Prime

Formato próximo do HotSpot mas com extensões para o coletor C4 (pausa sub-milissegundo) e para o Falcon JIT. Threads de compilação aparecem com prefixoC2 Compiler ou Falcon.

GraalVM

Compatível com HotSpot quando rodando como JIT polyglot. Em modo native image, o dump usa convenção própria — sem stack do interpretador, já que tudo foi compilado AOT.

Exemplo prático interpretado

Para dar concretude ao que o relatório entrega, considere o trecho abaixo, típico de uma aplicação Spring que ficou lenta para responder:

"http-nio-8080-exec-7" #142 daemon prio=5 os_prio=0 tid=0x00007f8b4c0a3000 nid=0x3a7d
   java.lang.Thread.State: BLOCKED (on object monitor)
   at com.exemplo.servico.PedidoService.atualizar(PedidoService.java:88)
   - waiting to lock <0x00000007a3c41e80> (a java.lang.Object)
   at com.exemplo.controller.PedidoController.put(PedidoController.java:54)
   at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
   ...

"http-nio-8080-exec-3" #137 daemon prio=5 os_prio=0 tid=0x00007f8b4c0b1800 nid=0x3a72
   java.lang.Thread.State: RUNNABLE
   at java.net.SocketInputStream.socketRead0(Native Method)
   at java.net.SocketInputStream.read(SocketInputStream.java:115)
   - locked <0x00000007a3c41e80> (a java.lang.Object)
   at com.exemplo.servico.PedidoService.consultarExterno(PedidoService.java:142)
   at com.exemplo.servico.PedidoService.atualizar(PedidoService.java:75)

A leitura aqui é imediata. A thread exec-3 está marcada como RUNNABLE, mas a pilha mostra socketRead0 — está travada num read de socket, sem timeout, segurando o monitor0x00000007a3c41e80. A thread exec-7está BLOCKED esperando exatamente esse mesmo monitor. Ou seja: uma chamada externa lenta contaminou o pool inteiro. A correção tem dois nomes: timeout no cliente HTTP e rever por que esse monitor está protegendo uma chamada de rede.

É exatamente essa leitura que o analisador faz sozinho: agrupa as threads BLOCKED pelo mesmo endereço de monitor, aponta quem o detém e monta o card de contenção com as threads envolvidas e a sugestão de correção — em um dump com 800 threads, sem você percorrer nenhuma delas.

Análise manual vs automática

A análise automática economiza tempo sempre que o dump é grande demais para ler linha a linha ou o relógio está correndo: incidente aberto em produção, dumps com centenas ou milhares de threads, triagem recorrente de vários dumps por dia. O trabalho mecânico — contar threads por estado, cruzar monitores, agrupar pilhas idênticas — é justamente o que a ferramenta faz em segundos e sem errar por cansaço.

A leitura manual continua valendo, principalmente para aprender: entender o que é um thread dump, o que cada estado (RUNNABLE, BLOCKED, WAITING, TIMED_WAITING) significa, quando capturar o dump e que padrões procurar é habilidade que todo dev Java com código em produção deveria ter. Quer aprender a ler thread dump na mão? Veja o guia completo de análise de thread dump, que cobre tudo isso em detalhe — estados, captura, padrões de problema e exemplos comentados.

Privacidade e dados do dump

Thread dumps são texto, mas não são inofensivos: as pilhas podem expor nomes de classes internas, endpoints, parâmetros de métodos e detalhes da sua infraestrutura. Trate o arquivo com o mesmo cuidado que você daria a um log de produção.

No ThreadMine, o dump é processado para gerar o relatório e você controla a exclusão — a retenção é limitada e a análise avulsa não exige cadastro. Se o seu contexto exige, remova dados sensíveis do texto antes do envio.