Before and after a real fix: see the delta

This page is a live, no-login demo of the rarest feature in a thread-dump analyzer: before/after comparison of an applied fix. The block above already tells the story — a Java service that was at health score 28 and, after a fix, went to 92. Below you explore the full diff that produced that number.

The scenario: exhausted pool + deadlock

The dump pair comes from a typical pedido-service on Spring Boot with Tomcat and HikariCP. In the before dump the service is stuck on two problems at once:

• Connection pool exhaustion. All five http-nio-8080-exec-* threads are BLOCKED/WAITING inside HikariPool.getConnection, parked past the connectionTimeout — piling up thousands of ms of CPU without making progress.
• Deadlock. pedido-tx-worker and estoque-tx-worker entered a circular wait on two monitors acquired in reversed order (CRITICAL).

In the after dump — same service, after bounding the pool and enforcing a global lock order — both problems disappear: the pool threads go back to RUNNABLE/TIMED_WAITING and the deadlock is gone. Nothing new shows up. That is the signature of a fix that landed.

How to read the delta

The read goes top to bottom, from summary to detail:

• Health score. 28 → 92. The single number that answers "better or worse?" before you read a single stack.
• Diagnosis. The green verdict and its drivers ("problem resolved") summarize, in one line, what pushed the score up.
• Counters and problems. BLOCKED 5 → 0, the CRITICAL problems that vanished, and the threads that released the most CPU.
• Thread-by-thread diff. Each paired thread, with its state transition (e.g. BLOCKED → RUNNABLE) and CPU delta. Filter by category, by state change, or by CPU released.

Why compare two dumps

A single dump answers "what is happening now?". Comparing two answers the question that actually matters after a change: "what changed?". That is what you want when validating a hotfix in production, investigating a regression between two deploys, or figuring out why latency rose between the 2pm and 3pm peaks. Reading two large dumps in parallel by hand is slow and error-prone; the diff shows only the delta.

How ThreadMine compares

ThreadMine pairs the threads of the two dumps by name and computes, for each one, changes in state, in locks (waited/held), in CPU and in stack (via a hash of the top frames). It aggregates counters by state, cross-references detected problems (what appeared in B, what disappeared from A, what changed severity) and derives a verdict with the main drivers of the change. On AI plans, Vein also writes an opinion on the likely cause of the difference.

The diff in this demo was computed by that exact same engine — the difference is that here the two dumps are a fixed example, served statically. With a free account you do the same with yours.