The ApacheCon thread-dump handbook explains thread dumps as textual snapshots of what every thread in a Java process is doing at the moment of capture. For serious performance problems, repeated snapshots often reveal the slow code path because many threads gather in the same few stack traces.

What a thread dump solves

Use thread dumps when a JVM application is hanging, stalling under load, timing out on requests, or showing clear throughput problems and you need to know whether threads are waiting on a backend call, a lock, or some other shared bottleneck.

What to check before you start

The source presentation is clear that you should exclude memory pressure and garbage collection behavior first. Thread dumps are excellent for serious runtime stalls and concurrency problems, but they are not a substitute for heap and GC analysis.

How to capture thread dumps

kill -QUIT <pid>: on Linux or Unix, this writes a thread dump to the JVM output stream without terminating the process.
jstack <pid> > dump.out: capture directly from a JDK installation.
jvisualvm: useful when a GUI is available.
Tomcat-specific notes: on Unix, a QUIT signal often lands in catalina.out; on Windows, some Tomcat installs expose a tray action for thread dumps.

Method that actually works

The ApacheCon guidance recommends taking more than one dump because a single dump is only a moment-in-time snapshot. A practical default is three dumps about three seconds apart. Then compare them and look for recurring hot stacks rather than unique one-off traces.

How to analyze the stacks

Ignore idle stacks that contain little or no application code.
Focus on the top 5-10 lines of the repeated stack traces.
Count which stacks appear most often across many threads.
Look for network waits such as socket reads or HTTP client reads.
Look for lock waits, blocked states, or synchronized hotspots that stop parallel execution.

Patterns you will often find

Repeated socket read stacks often point to slow backend services such as databases, RPC, middleware, or HTTP dependencies. Repeated blocked or lock-related stacks point to concurrency bottlenecks. Small repeated stacks around pools, caches, or timeouts can point to sizing mistakes rather than code defects.

Know the limits

Thread dumps are not tracing, not heap dumps, and not full performance monitoring. They give you a snapshot of where threads are, not the full data context. That is why repeated dumps and corroborating evidence matter.

From capture to escalation

Strong escalation notes include the capture method, timestamps, number of dumps taken, the most frequent repeated stack, whether it points to network wait or lock contention, and what surrounding evidence exists from logs or metrics.

Recommended resources

Manual references stay pinned first, and AI adds extra official or trusted links matched to the lesson topic.

Java Thread Dump Analysis