Thread dump vs heap dump: qual dos dois você precisa?

Os dois arquivos nascem nos mesmos momentos ruins — uma queda, um OutOfMemoryError, uma JVM que parou de responder — e os nomes são parecidos o bastante para se buscar um precisando do outro. A distinção vale trinta segundos, porque analisar o snapshot errado desperdiça uma hora: o thread dump diz o que a JVM está fazendo; o heap dump diz o que a JVM está segurando.

Este guia cobre o que cada snapshot contém, qual sintoma pede qual, como capturar os dois sem machucar a produção e qual ferramenta lê cada um. Uma nota honesta logo de cara: o ThreadMine analisa dumps de thread — para heap dumps, vamos apontar as ferramentas certas em vez de fingir.

Dois snapshots, duas perguntas

• Thread dump — "o que cada thread está fazendo agora?" Um snapshot em texto de cada thread viva: o stack trace, o estado (RUNNABLE, BLOCKED, WAITING…) e os locks que ela segura ou espera. Kilobytes de tamanho, capturado em milissegundos. A ferramenta para travamentos, deadlocks, picos de CPU e pools esgotados.
• Heap dump — "o que está enchendo a memória?" Um snapshot binário (em geral um arquivo .hprof) de todos os objetos do heap: a classe, os campos e quem referencia cada um. Do tamanho do próprio heap — com frequência, gigabytes. A ferramenta para memory leaks e OutOfMemoryError: Java heap space.

Os dois são complementares, não rivais. Um incidente sério de memória costuma usar ambos: o heap dump nomeia os objetos que encheram a memória, e o thread dump mostra quais caminhos de código estavam ocupados criando esses objetos quando a música parou.

O que tem dentro de um thread dump

Uma entrada por thread, e cada entrada é uma história: o nome da thread, o estado, a pilha completa do que ela executava e as linhas de monitor/lock que a conectam às outras threads.

"http-nio-8080-exec-7" #41 daemon prio=5 tid=0x... nid=0x2f03 waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
	at com.example.Cache.get(Cache.java:42)
	- waiting to lock <0x000000076ab00000> (a com.example.Cache)
	at com.example.Api.handle(Api.java:88)

Como é texto puro e custa quase nada para produzir, o conselho padrão é capturar vários dumps com alguns segundos de intervalo e compará-los — uma thread presa no mesmo lock em três snapshots é um achado; uma thread vista esperando uma única vez é só uma terça-feira. Ler esses padrões em escala é exatamente o que um analisador automatiza: o nosso guia completo de análise de thread dump percorre a versão manual.

O que tem dentro de um heap dump

Todos os objetos vivos no heap naquele instante, com os valores reais dos campos e o grafo completo de referências — quem aponta para quem. Esse grafo é o que torna a análise de memory leak possível: um analisador de memória calcula a dominator tree e consegue dizer "este HashMap retém 3,2 GB", ou que um classloader parado continua preso por um único listener. Nada dessa informação existe num thread dump — pilhas referenciam código, não conteúdo de objetos.

O preço é física: o arquivo tem mais ou menos o tamanho do heap usado, escrevê-lo pausa a JVM, e abri-lo pede uma máquina parruda. Heap dump é bisturi — preciso, e não algo que se aponta para a produção a cada poucos segundos.

Qual snapshot para qual sintoma

A última linha é a que surpreende: um OutOfMemoryError não significa automaticamente "heap dump". Quando a mensagem é unable to create new native thread, a memória está bem — o processo ficou sem threads, e um thread dump mostrando 4.000 workers chamados pool-7-thread-N é o diagnóstico inteiro.

Como capturar cada um

Thread dump — qualquer um destes, contra o pid da JVM:

jstack -l <pid> > dump.txt          # o clássico
jcmd <pid> Thread.print > dump.txt   # o equivalente moderno
kill -3 <pid>                        # sem ferramentas do JDK? o dump vai pro stdout

Tire pelo menos três, com alguns segundos de intervalo. Achar o pid, Windows, containers e Spring Boot Actuator estão cobertos em como capturar um thread dump.

Heap dump — mesmas ferramentas, verbos diferentes:

jcmd <pid> GC.heap_dump /tmp/heap.hprof        # moderno
jmap -dump:live,format=b,file=heap.hprof <pid>  # clássico ("live" roda um full GC antes)

# seguro — configure ANTES do incidente:
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps ...

Essa última flag é a observabilidade mais barata que você vai configurar na vida: a JVM escreve o heap dump no momento exato do OutOfMemoryError, quando a evidência ainda está na sala.

Custo e segurança em produção

• Thread dump: tire à vontade. A pausa de safepoint é de milissegundos, o arquivo é texto pequeno, e capturas repetidas não são só seguras — são a técnica recomendada.
• Heap dump: planeje. A JVM pausa enquanto o heap inteiro é escrito em disco — segundos a minutos em heaps grandes — e o arquivo precisa de tanto disco livre quanto o heap tem de tamanho. Num nó já sofrendo, essa pausa é visível para os usuários.
• Eles diferem em sensibilidade também. O heap dump contém os seus dados de verdade: strings, registros de usuário, tokens — o que estivesse em memória. Trate o arquivo como um extrato do banco. O thread dump expõe nomes de classe, stack traces e nomes de thread — interno, mas em outra liga.

A ferramenta certa para cada lado

Para heap dumps, a referência é o Eclipse Memory Analyzer (MAT) — gratuito, com relatório de leak suspects e a dominator tree que faz a conta de retenção por você. O VisualVM dá uma primeira olhada mais leve, e profilers comerciais (JProfiler, YourKit) embutem a mesma análise no seu ferramental. Também existem opções hospedadas (HeapHero, da mesma família do fastThread). O ThreadMine não analisa heap dumps — se o arquivo termina em .hprof, essas são as suas ferramentas.

Para thread dumps, você pode ler o texto na mão — linha por linha — ou entregar o reconhecimento de padrões a um analisador de thread dump online grátis: cole o dump, sem cadastro, e o ThreadMine detecta deadlocks, pool exhaustion, thread leaks e pinning de virtual threads automaticamente, dá uma nota de saúde ao snapshot e costura vários dumps numa timeline. Prefere ler a olho com uma ferramenta desktop? Também funciona — nós nos comparamos honestamente com o IBM TMDA e o jstack.review, incluindo quando eles bastam.

Seja qual for o lado desta página que te trouxe aqui: capture primeiro o snapshot barato, guarde o caro para sintomas com cara de memória, e deixe cada arquivo ser lido pela ferramenta que nasceu para ele.