DevStudio's Thread Dump Analyzer turns raw Java thread dumps — the output of jstack, kill -3, the JFR thread snapshot, the management bean dump, or a stack section pulled out of an OutOfMemoryError fatal log — into an interactive overview that highlights deadlocks, contention hot spots, and thread-state distribution. Paste one or several dumps and the tool parses thousands of stack frames in your browser, classifies every thread by state — RUNNABLE, BLOCKED, WAITING, TIMED_WAITING — groups threads by stack-trace prefix so identical workers collapse into a single row with a count, surfaces lock owners and waiters, and renders pie and bar charts of state and group distribution that make it obvious whether a JVM is busy, idle, or stuck. Built-in deadlock detection walks the lock-ownership graph and explicitly flags cycles, with a one-click jump from each cycle to the offending stacks. Comparing up to three dumps side by side is the canonical workflow for diagnosing a slow operation: capture before, during, and after, paste all three into the analyzer, and the comparison view shows which threads moved between states, which are stuck on the same lock across the snapshots, and which appeared or vanished. Search lets you filter by class name, method, lock object identity hash, or thread name fragment so a single suspicious frame can be traced through every thread that touched it. Common use cases include diagnosing a hung Spring Boot pod, identifying a runaway scheduler in a Kafka consumer, finding the blocking IO call in a JDBC pool exhaustion, isolating the parking-lot wait in a slow ForkJoinPool task, and confirming whether a deadlock is the root cause of a periodic stall. Because every dump is parsed locally inside your browser, the stack traces — which often expose internal class names, customer identifiers in method arguments, or proprietary code paths — never leave your device. The tool is safe to use against production captures where uploading would violate intellectual property or compliance policies.
From the command line use jstack with the JVM's process ID, for example jstack 12345, to print the stack of every thread to standard out. On Linux you can also send kill -3 to the JVM, which writes the dump to the process's standard error stream. Modern JVMs additionally expose dumps through the management bean ThreadMXBean dumpAllThreads call and through Java Flight Recorder snapshots; any of these formats parses cleanly in DevStudio Thread Dump Analyzer.
A deadlock appears as a cycle in the lock-ownership graph: thread A waits on a monitor held by thread B, while B waits on a monitor held by A. Manually you would search for BLOCKED threads, follow the waiting-on entry, and check whether the owner is in turn blocked on something you hold. DevStudio's analyzer walks this graph automatically and flags every cycle, naming each thread and the monitor it is waiting on, so the diagnosis is immediate.
A single dump shows the JVM at one instant, which can be misleading — a thread might happen to be RUNNABLE only because it just resumed for that microsecond. Capturing several dumps a few seconds apart reveals which threads are persistently stuck versus merely passing through. DevStudio's compare-up-to-three feature aligns the dumps side by side and highlights threads that remained in the same state on the same lock, which is the canonical signature of a real stall rather than a sampling artifact.
BLOCKED means a thread is waiting to acquire an intrinsic monitor — a synchronized block or method — that another thread currently owns. Unlike WAITING, which is a voluntary call to Object.wait or LockSupport.park, BLOCKED happens because of contention rather than coordination. A handful of BLOCKED threads at a given instant is normal in any concurrent JVM; many BLOCKED threads on the same monitor across consecutive dumps indicates a real bottleneck or a potential deadlock.
No. DevStudio's Thread Dump Analyzer parses every dump entirely inside your browser. The stack traces, lock ownership, thread names, and any state captured in method arguments stay on your device — there is no upload step, no telemetry on the dump contents, and no third-party logging. This matters because production thread dumps frequently expose internal class names, customer identifiers, or proprietary algorithms that should not leave your environment.