Java Thread Dump Debugging Guide
Use Java thread dumps to investigate stuck requests, blocked threads, deadlocks, high CPU and service timeouts. This Formalint reference is written for working developers, DBAs and support engineers who need a repeatable debugging path instead of a one-line snippet with no context.
Use the notes below as a practical review order: understand the input, capture evidence, make one small change and verify the result before moving to the next assumption.
When to use this page
Capture JVM evidence before restarting the service. It is most useful when a small validation or debugging mistake can create noisy tickets, misleading logs or hard-to-review production changes.
Practical workflow
| Step | What to confirm |
|---|---|
| Find the JVM process | Record PID, command line and service name. |
| Capture multiple dumps | Two or three dumps a few seconds apart show whether threads are moving. |
| Connect to symptoms | Compare blocked threads with API timeouts, database locks and CPU spikes. |
Thread dump commands
jcmd <pid> Thread.print
jstack <pid>
ps -ef | grep java
top -H -p <pid>Review checklist
- Capture before restart when the process is still alive.
- Redact sensitive strings from dumps before sharing.
- Look for BLOCKED, WAITING and repeated stack frames.
- Compare with GC and memory evidence.
- Keep timestamps for each dump.
Common mistake
One dump is a snapshot. Multiple dumps tell a story.
Formalint is strongest when the page helps the developer decide what the tool cannot prove. Treat every formatter, regex and command as one layer of evidence, not the whole truth.
Frequently asked questions
Does a thread dump stop the JVM?
It is normally a diagnostic action, but still run it according to production policy.
What is a deadlock?
Two or more threads are waiting on locks in a cycle, so none can continue.
Related Formalint references
Continue with Java Memory Debugging, Api Timeout Debugging Guide, PostgreSQL Lock Debugging.