Thread Dump Analysis: Diagnose Hangs and Deadlocks

A thread dump shows every thread in the JVM at an instant: its state (RUNNABLE, WAITING, BLOCKED, TIMED_WAITING), its lock if it's waiting, and its full stack. It is the primary evidence for hangs, deadlocks, and 'why is nothing happening' questions.

The skill is pattern recognition: a handful of thread dumps taken a few seconds apart, plus knowledge of the states, turns a cryptic stack into a named culprit almost every time.

Capture two or three dumps

One dump can catch transients; two-to-three a few seconds apart confirm a genuine hang.

for i in 1 2 3; do
  # modern: jcmd Thread.print -l ; classic: jstack -l
  jcmd <pid> Thread.print -l > threads-$i.txt
  sleep 5
done
# diff normalized lines to see what didn't move
diff <(cut -c1-140 threads-1.txt) <(cut -c1-140 threads-2.txt)

Read the thread states

Each thread line starts with its name and state. RUNNABLE at high CPU = working (or spinning); WAITING/TIMED_WAITING = parked on a monitor or lock; BLOCKED = contending for a monitor owned by another thread.

Find the deadlock

jstack prints 'Found one Java-level deadlock' with the implicated threads and the lock cycle automatically. If it's not detected, look for two threads each holding a lock the other wants.

jstack <pid> | grep -A 15 -i deadlock

Spot the common hang culprits

Blocked on an InputStream/socket read, on a connection pool lock, or inside an RMI/Object wait — these match symptom to subsystem. Pair the stuck frame with the owning thread's stack to see the full picture.

Tooling to make dumps readable

For hundreds of threads, the thread-dump view in JDK Mission Control or VisualVM, or a dedicated analyzer like TDA, collapses threads by state and flag repeats.

# Open the raw dump in JMC (File > Open) or
# paste into a thread-dump analyzer for grouped view