A thread dump is a snapshot of every thread in a Java Virtual Machine at one moment. It records thread states, stack traces, resource use, blocking relationships, and held or requested locks. section 8.0 section 8.2.1
Use one when an application freezes, stops responding, or shows threading problems. Unlike profiling, which samples execution over time, a thread dump provides a single still image that can be collected while the application is stuck. section 1.2.4 section 8.3
A practical investigation proceeds through these steps:
- Collect a dump with a profiler such as VisualVM or JProfiler, or identify the Java process with jps and run jstack against its process ID. section 8.1.1 section 8.1.2
- Read each thread’s name, JVM and native identifiers, state, stack trace, CPU time, blocking thread, requested locks, and held locks. section 8.2.1
- For a suspected deadlock, filter for blocked threads, follow each requested lock to its owner, and continue until the dependency path returns to an already examined thread. section 8.2.1
- Save raw output when necessary, then load it into a profiler or visualize it with fastThread; treat AI suggestions as clues rather than conclusions. section 8.1.2 section 8.2.2
Opposite lock order creates a deadlock
Suppose a Consumer thread enters synchronized(listA) and then requests listB, while a Producer thread enters synchronized(listB) and then requests listA. Each thread can hold one monitor while waiting for the other. A dump reports both threads as BLOCKED and exposes the opposing lock IDs, making the cycle visible even though the application has frozen. section 8.1
Figure 8.8 To find a deadlock with a thread dump, follow these three easy steps. First, remove all threads that are not blocked. Then, start with one of the blocked threads and find what is blocking it using the lock ID. Continue this process for each thread. If you return to a thread you already investigated, it means you found a deadlock.
Use the three-step deadlock path: discard nonblocked threads, follow each blocked thread’s lock dependency, and identify the cycle when the path returns to a known thread. section 8.2.1
