Thread Dumps and Deadlock Analysis
Fast recall
Quick revision
Core answer
Practical debugging skill for concurrency issues in production
Taking one thread dump vs three — one snapshot can be misleading. Three dumps 5 seconds apart reveal whether threads are stuck or just slow
Explain how to distinguish deadlock from thread starvation and from waiting for external I/O
Interview-ready guide
Interview answer
Thread dumps capture the state of every thread at a moment in time — they're the primary tool for diagnosing live hangs, high CPU, and deadlocks.
Capturing thread dumps:
jstack: on-demand snapshot from the command linekill -3on Linux: writes dump to stdout/log without stopping the processThreadMXBean.findDeadlockedThreads(): programmatic detection for health-check endpoints
Reading a thread dump:
- BLOCKED threads all pointing to the same monitor → lock contention; the lock-holder is identified in the dump
- Repeated identical RUNNABLE stacks → CPU-burning loop or active spin
- WAITING threads in
java.util.concurrentstructures → normal producer-consumer; check if they ever wake
Deadlock detection:
jstackautomatically detects monitor cycles and prints "Found N deadlock" at the bottom- Shows which thread holds which lock and which lock it needs — the cycle is immediately visible
Prevention:
- Lock ordering: always acquire locks in the same predetermined order — circular wait condition can't form
ReentrantLock.tryLock(timeout): bounded wait instead of indefinite blocking
I recommend setting up ThreadMXBean.findDeadlockedThreads() in a health-check endpoint so deadlocks surface in monitoring before users report a frozen service.
Thread Dumps and Deadlock Analysis
Direct Answer
Take thread dumps with jstack <pid> or kill -3 <pid>. Look for BLOCKED threads with conflicting lock patterns. Deadlocks show as cycles in the waiting-for chain. JVM automatically detects deadlocks and reports them at the bottom of the thread dump.
Deep Dive & Architecture
Java Flight Recorder (JFR) is a low-overhead event recorder built directly into the HotSpot JVM.
It captures GC events, CPU samples, thread states, lock contention, allocation patterns, JIT compilation, class loading, and I/O — all in a single recording with under 1% overhead.
Open-sourced in Java 11, JFR is designed to run continuously in production. Start it via -XX:StartFlightRecording=... at JVM launch or on-demand with jcmd <pid> JFR.start. Analyze the resulting .jfr file in JVM Mission Control (JMC) for correlated timeline views, or query the events programmatically via the jdk.jfr.consumer API. JFR is the right tool for after-the-fact diagnosis — when monitoring shows a latency spike, JFR tells you what was happening inside the JVM at that moment.
A common mistake is using JMH micro-benchmarks or YourKit in production to investigate latency, then drawing wrong conclusions because the instrumentation itself caused the slowdown
Common Mistakes & Pitfalls
Taking one thread dump vs three — one snapshot can be misleading. Three dumps 5 seconds apart reveal whether threads are stuck or just slow
Check your understanding
Answer these without looking back at the article.
- How do you profile a Java application in production? What tools do you use?
- What is Java Flight Recorder? How do you capture and analyze JFR recordings, and when is it the right tool?
- How do you profile a Java application? Explain the difference between sampling and instrumenting profilers and when to use each.
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.