Code10x
Thread problemsmedium3-5 years

`jcmd <pid> Thread.print` prints "Found one Java-level deadlock" with two threads, each shown as waiting on a lock the other holds. How does the JVM actually determine this is a deadlock rather than just two threads that happen to be blocked, and what can this detector not see?

The JVM isn't guessing from symptoms — it builds an actual graph. Every thread that's blocked waiting for a monitor is an edge pointing from that thread to whoever currently holds it; a thread that both holds one monitor and is waiting on another contributes a second edge. The detector walks this "wait-for" graph looking for a cycle — a path of waiting-for edges that loops back to where it started — and reports a deadlock exactly when it finds one, which is why the dump can name the exact threads and locks involved rather than just observing that things look stuck. What it can't see is anything that leaves the JVM: two separate processes each waiting on a lock the other holds, or two database transactions each waiting on a row the other has locked — those need their own detectors, which is why a database deadlock shows up as an exception the application catches, not a JVM-reported deadlock.

The lesson behind it →
PreviousA heap dump's dominator tree ranks a `Map` object at the top by retained size, but its own shallow size is 48 bytes — smaller than almost everything else in the heap. A teammate is confused: "how can something that small be the leak?" Walk through what retained size means and why sorting by it, not shallow size, is what actually finds the root cause.Next Two services both show requests hanging with low CPU. In the first, `jcmd <pid> Thread.print` shows every thread in a four-thread pool parked in the same stack frame calling a downstream dependency. In the second, five threads are BLOCKED on the same monitor address, one thread holds it. Are these the same problem, and does adding more threads to the pool help either one?
More on Thread problems
Two services both show requests hanging with low CPU. In the first, `jcmd <pid> Thread.print` shows every thread in a four-thread pool parked in the same stack frame calling a downstream dependency. In the second, five threads are BLOCKED on the same monitor address, one thread holds it. Are these the same problem, and does adding more threads to the pool help either one?