Cole um dump ou abra um arquivo para examinar as threads capturadas. A análise relaciona os dados desse instante; não monitora uma JVM em execução.
Funciona localmente no seu navegadorCole a saída do jstack ou do jcmd Thread.print, ou abra um arquivo .txt ou .log, e pressione Analisar localmente. O dump é lido neste navegador: o resumo conta as threads por java.lang.Thread.State, o cartão de baixo classifica os frames de pilha que se repetem e os achados nomeiam as threads que esperam um lock mantido por outra.
Um dump de 13 threads e 4,3 KB voltou como RUNNABLE 4, WAITING 3, BLOCKED 2, TIMED_WAITING 2 e UNKNOWN 2, com java.base/java.lang.Thread.sleep(Native Method) como frame mais repetido (3 threads) e duas threads HTTP esperando o monitor que a cache-writer mantinha. Nada é enviado e nenhuma cópia do dump é guardada.
Só texto é analisado, e só nas formas que um dump da JVM escreve: cabeçalhos de thread (nome entre aspas seguido de prio=, tid= ou nid=), linhas java.lang.Thread.State, frames at e as linhas waiting to lock / locked / parking to wait for que o jstack -l acrescenta. Threads da VM são impressas sem linha de estado, então caem na linha UNKNOWN — duas das treze do exemplo acima.
O relatório de deadlock que o jstack anexa depois da lista de threads é lido como relatório, não como novas threads: um dump com três threads e um deadlock continua com três threads, e o relatório vira um achado mais uma linha por par em espera.
Todo frame de toda thread conta, não apenas os três mais internos, porque um frame compartilhado mais fundo na pilha é exatamente a marca de um caminho de chamada repetido. Em um exemplo de 24 threads cujo quinto frame é java.base/java.lang.reflect.Method.invoke(Method.java:568), esse frame aparece 18 vezes no dump e na tabela.
Uma correlação de lock precisa das duas metades no mesmo dump: a linha waiting to lock <id> de uma thread e a linha locked <id> de outra. Locks cujo dono não está no arquivo — dump truncado ou jstack sem -l — continuam contados como espera, mas nada é afirmado sobre quem os mantém.
O tamanho não é limite prático: um dump de 240 threads e 92 KB voltou com 240 threads, 6 delas bloqueadas em um único monitor e três frames contados 240 vezes cada, porque o trabalho acontece nesta máquina.
Um log de falha do HotSpot (hs_err_pid*.log) lista threads Java mas não traz nenhuma linha java.lang.Thread.State, então a página diz isso em vez de desenhar tabelas vazias. Qualquer outro texto sem um único cabeçalho de thread recebe a mesma resposta, e uma caixa vazia recebe um aviso em vez de um resultado.
Lê-se um dump por vez. O analisador não se conecta a uma JVM, não amostra um processo em execução nem observa mudanças em um arquivo; para uma visão ao vivo, o Flight Recorder ou um profiler são a ferramenta certa.
Nomes de estado, assinaturas de frame e identificadores de lock são impressos exatamente como o dump os escreve, em inglês, porque são dados; os rótulos ao redor seguem o idioma da página.