How do I analyze a Java thread dump?

Paste output from jcmd Thread.print or jstack, or open a text or JSON dump file. The analyzer groups states and stacks, traces lock ownership, and highlights deadlocks and contention.

Does the analyzer support Java virtual threads?

Yes. It reads modern JDK JSON thread dumps produced by Thread.dump_to_file and identifies virtual threads, containers, states, stacks, blockers, and carrier details when present.

Is my thread dump uploaded?

No. Parsing, searching, grouping, lock analysis, and report generation run locally in the browser.

Java Thread Dump Analyzer

Free · Browser only

Turn a wall of JVM stacks into a diagnosis. Find deadlocks, blocked threads, contended monitors, repeated pool stacks, common frames, and virtual-thread activity without uploading the dump.

Paste or open a thread dump

HotSpot/OpenJDK text, multiple concatenated captures, or modern JDK JSON · up to 20 MB

Open dump file

2026-09-03 12:00:00
Full thread dump OpenJDK 64-Bit Server VM (24 mixed mode):

"main" #1 prio=5 os_prio=0 cpu=120.5ms elapsed=45.2s tid=0x1 nid=0x1 runnable
   java.lang.Thread.State: RUNNABLE
        at com.example.Main.loop(Main.java:42)
        at com.example.Main.main(Main.java:18)

"order-worker-1" #21 prio=5 os_prio=0 tid=0x21 nid=0x21 waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.OrderService.reserveInventory(OrderService.java:110)
        - waiting to lock <0x0000000000000bbb> (a java.lang.Object)
        - locked <0x0000000000000aaa> (a java.lang.Object)
        at com.example.OrderService.placeOrder(OrderService.java:72)

"order-worker-2" #22 daemon prio=5 os_prio=0 tid=0x22 nid=0x22 waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.OrderService.chargePayment(OrderService.java:145)
        - waiting to lock <0x0000000000000aaa> (a java.lang.Object)
        - locked <0x0000000000000bbb> (a java.lang.Object)
        at com.example.OrderService.placeOrder(OrderService.java:76)

"http-nio-8080-exec-1" #30 daemon prio=5 os_prio=0 tid=0x30 nid=0x30 waiting on condition
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0000000000000ccc> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)

"http-nio-8080-exec-2" #31 daemon prio=5 os_prio=0 tid=0x31 nid=0x31 waiting on condition
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0000000000000ddd> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)

"HikariPool-1 housekeeper" #40 daemon prio=5 os_prio=0 tid=0x40 nid=0x40 waiting on condition
   java.lang.Thread.State: TIMED_WAITING (parking)
        at jdk.internal.misc.Unsafe.park(Native Method)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:269)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)

Found one Java-level deadlock:
=============================
"order-worker-1":
  waiting to lock monitor 0x1 (object 0x0000000000000bbb, a java.lang.Object),
  which is held by "order-worker-2"
"order-worker-2":
  waiting to lock monitor 0x2 (object 0x0000000000000aaa, a java.lang.Object),
  which is held by "order-worker-1"

Found 1 deadlock.

Pasted text is analyzed automatically. Nothing leaves this browser.

Analysis summary

All threads

Runnable

Blocked

Waiting

Timed waiting

Deadlock cycles

What deserves attention

Thread distribution

By state

By role

Common stack frames

Across distinct threads

Deadlock cycles

Lock ownership and waiters

Locks with identifiable contention, shared waiters, or unusual multiple owners are listed.

Lock	Type	Owner	Waiting threads

From capture to diagnosis

Capture useful lock data

For platform threads, use jcmd <pid> Thread.print -l or jstack -l <pid>. The lock option adds ownable synchronizers, improving waiter-to-owner analysis.

Compare several moments

For hangs or suspected CPU loops, capture multiple dumps several seconds apart and paste them together. A thread that stays RUNNABLE at the same frame across captures deserves closer investigation.

Modern virtual-thread dumps

JSON output from jcmd <pid> Thread.dump_to_file -format=json file.json preserves thread containers and scales better for large virtual-thread workloads.

What the Java thread states tell you

BLOCKED means a thread is waiting to enter synchronized code. WAITING and TIMED_WAITING commonly describe parked pool workers, sleeps, joins, or condition waits. RUNNABLE is broader than “using CPU”: it can include native work and some I/O. The analyzer keeps these states separate and connects monitor waiters to identifiable lock owners.

Supported thread-dump sources

Use traditional HotSpot or OpenJDK output from jstack, jcmd Thread.print, a kill -3 capture, or several captures concatenated into one file. Modern Thread.dump_to_file -format=json output is also supported for container and virtual-thread inspection.

New to the evidence? Read how to read a Java thread dump and trace a deadlock. Investigating a wider JVM incident? Use the X.509 certificate inspector for TLS material or the DDL schema explorer when a database call in the stack needs context.

This is static evidence analysis, not a profiler. Confirm suspicious patterns with repeated captures, JFR, application metrics, or a profiler.

Java Thread Dump Analyzer

Paste or open a thread dump

Analysis summary

What deserves attention

Thread distribution

By state

By role

Common stack frames

Capture comparison

Stack trace

Locks held

Repeated stack groups

Deadlock cycles

Lock ownership and waiters

From capture to diagnosis

Capture useful lock data

Compare several moments

Modern virtual-thread dumps

What the Java thread states tell you

Supported thread-dump sources

Java Thread Dump Analyzer

Paste or open a thread dump

Analysis summary

What deserves attention

Thread distribution

By state

By role

Common stack frames

Capture comparison

Stack trace

Locks held

Repeated stack groups

Deadlock cycles

Lock ownership and waiters

From capture to diagnosis

Capture useful lock data

Compare several moments

Modern virtual-thread dumps

What the Java thread states tell you

Supported thread-dump sources

Send Feedback