Java thread dump analyzer — online, free and automatic

A thread dump analyzer removes the mechanical part of diagnosis: instead of reading hundreds of stacks by hand looking for the contended lock or the stuck thread, you upload the file and get the problems already identified, with a severity and a root cause. When the application is slow in production and the incident is open, that difference is measured in minutes — not hours.

The ThreadMine analyzer reads dumps from HotSpot, OpenJ9, Azul Zing and GraalVM without your having to say which format it is, runs 15 detectors over the normalized content, and returns a report with a health score, problem cards and prioritized suggestions. Online, free and with no sign-up to get started.

How the analyzer works

It is three steps, from the raw file to the diagnosis:

1. Submit the dump. Open the home page, paste the dump text or upload the file — no sign-up.
2. The parser identifies the JVM automatically. From the header and the structure, the analyzer recognizes whether the dump came from HotSpot, OpenJ9, Zing or GraalVM and normalizes everything to a single model.
3. Get the report. A health score from A to F, a list of detected problems with severity, the threads involved, and a suggested root cause for each one.

What the analyzer detects

Among the detectors that run on every analysis, the most sought-after:

• Deadlock — lock cycles between threads, including the ones the JVM has already declared in the Found one Java-level deadlock section.
• Pool exhaustion — every thread in a pool (Tomcat, executor, connections) busy at the same time, with the queue growing.
• CPU spike — a cluster of RUNNABLE threads in hot methods: infinite loops, a catastrophic regex, serialization of huge objects.
• Thread leak — threads outside any pool that only keep growing, typically an ExecutorService that is never shut down.
• Lock contention — many BLOCKED threads fighting over the same monitor, with the holder of the lock identified.
• Virtual-thread pinning — virtual threads (Loom) pinned to the carrier thread by synchronized blocks or native code.

The format of each JVM

Each JVM implementation emits the dump in its own format — and the analyzer accepts all four with no configuration, detecting the format from the header and the structure. It is worth knowing the differences so you know what to expect from the file.

HotSpot (OpenJDK, Oracle JDK)

It is the most common format. It starts with the Full thread dump OpenJDK 64-Bit Server VM header, followed by the threads and, at the end, an optional JNI global references section. When there is a deadlock, the Found one Java-level deadlock section appears after the threads.

OpenJ9 (Eclipse / IBM)

More verbose. It emits files in the javacore.txt format with named sections (THREADS, CLASSES, MEMINFO, LOCKS). It is useful because it already includes a memory diagnosis alongside. Typically triggered by a signal or by the jdmpview tool.

Azul Zing / Prime

A format close to HotSpot but with extensions for the C4 collector (sub-millisecond pauses) and the Falcon JIT. Compilation threads show up with a C2 Compiler or Falcon prefix.

GraalVM

Compatible with HotSpot when running as a polyglot JIT. In native-image mode, the dump uses its own convention — no interpreter stack, since everything was compiled AOT.

A worked example, interpreted

To make what the report delivers concrete, consider the excerpt below, typical of a Spring application that became slow to respond:

"http-nio-8080-exec-7" #142 daemon prio=5 os_prio=0 tid=0x00007f8b4c0a3000 nid=0x3a7d
   java.lang.Thread.State: BLOCKED (on object monitor)
   at com.exemplo.servico.PedidoService.atualizar(PedidoService.java:88)
   - waiting to lock <0x00000007a3c41e80> (a java.lang.Object)
   at com.exemplo.controller.PedidoController.put(PedidoController.java:54)
   at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
   ...

"http-nio-8080-exec-3" #137 daemon prio=5 os_prio=0 tid=0x00007f8b4c0b1800 nid=0x3a72
   java.lang.Thread.State: RUNNABLE
   at java.net.SocketInputStream.socketRead0(Native Method)
   at java.net.SocketInputStream.read(SocketInputStream.java:115)
   - locked <0x00000007a3c41e80> (a java.lang.Object)
   at com.exemplo.servico.PedidoService.consultarExterno(PedidoService.java:142)
   at com.exemplo.servico.PedidoService.atualizar(PedidoService.java:75)

The reading here is immediate. Thread exec-3 is marked as RUNNABLE, but the stack shows socketRead0 — it is stuck in a socket read, with no timeout, holding the monitor 0x00000007a3c41e80. Thread exec-7 is BLOCKED waiting for that exact same monitor. In other words: one slow external call has poisoned the entire pool. The fix has two names: a timeout on the HTTP client, and rethinking why that monitor is guarding a network call.

This is exactly the reading the analyzer does on its own: it groups the BLOCKED threads by the same monitor address, points to who holds it, and builds the contention card with the threads involved and the suggested fix — in a dump with 800 threads, without your walking through a single one of them.

Manual vs. automatic analysis

Automatic analysis saves time whenever the dump is too large to read line by line or the clock is running: an incident open in production, dumps with hundreds or thousands of threads, recurring triage of several dumps a day. The mechanical work — counting threads by state, cross-referencing monitors, grouping identical stacks — is precisely what the tool does in seconds and without erring out of fatigue.

Manual reading still has its place, above all for learning: understanding what a thread dump is, what each state (RUNNABLE, BLOCKED, WAITING, TIMED_WAITING) means, when to capture the dump, and which patterns to look for is a skill every Java dev with code in production should have. Want to learn to read a thread dump by hand? See the complete guide to thread dump analysis, which covers all of this in detail — states, capture, problem patterns, and annotated examples.

Privacy and the data in your dump

Thread dumps are text, but they are not harmless: the stacks can expose the names of internal classes, endpoints, method parameters, and details of your infrastructure. Treat the file with the same care you would give a production log.

At ThreadMine, the dump is processed to generate the report and you control its deletion — retention is limited and the one-off analysis requires no sign-up. If your context demands it, remove sensitive data from the text before submitting.