Taking and interpreting a JVM thread dump

Jump to bottom

Kevin Walter edited this page Dec 16, 2019 · 6 revisions

Introduction

Ever wanted to know what's going on exactly in the JVM, when a debugger is not available (eg. at a customer?)

A thread dump will provide an instant snapshot of all stacks, in all threads. Sometimes that is sufficient.

How to take a dump

# Tomcat
kill -3 `ps aux | grep catalina.startup | grep -v grep | awk '{print $2}'`
# Taskomatic
kill -3 `ps aux | grep TaskomaticDaemon | grep -v grep | awk '{print $2}'`

For ibm java:

This will not kill the JVM but it will produce a dump file. Location of this file depends on the process:

Tomcat will create /usr/share/tomcat/javacore.<DATE>.<TIME>.<PID>.<NUMBER>.txt
Taskomatic will create /var/crash/javacore.<DATE>.<TIME>.<PID>.<NUMBER>.txt

For openjdk: This will output the treaddump into journalctl -u tomcat/taskomatic.

Alternatively the utility jstack in the package java-11-openjdk-devel can print a thread dump to the terminal so it can easily piped to a file.

Interpreting a dump

Usually interesting lines are threads (starting with 3XMTHREADINFO), states might be:

R: running or ready to run
CW: waiting on wait, join, or for I/O
B: Blocked, the thread is waiting to obtain a lock that something else currently owns
P: explicitly parked
S: Suspended, the thread has been suspended by another thread
Z: Zombie, the thread has been killed

After that line a full stack trace is provided.

More information:

Tool to analyse dumps

JCA