How do you detect and quantify lock contention in a running Java application?

## Why you must measure, not guess Contention is invisible in source code — whether a lock is hot depends on runtime access patterns and load. Optimizing the wrong lock wastes effort and adds risk. So the discipline is: **observe first, then act on the proven hot lock.** ## Signal 1 — Thread dumps (free, always available) A **thread dump** is a snapshot of every thread's state and stack. Capture it with `jstack <pid>` or `jcmd <pid> Thread.print` (take 2–3 a few seconds apart). What to look for: - Many threads in state **`BLOCKED`** with a line like `waiting to lock <0x000000076b...>` — and several of them waiting on the **same** monitor address. That's active contention on that lock. - The thread that **owns** that monitor (`locked <0x...076b...>`): its stack shows *what work* is being done under the lock — often the real fix is to make that work shorter or move it out. - `BLOCKED` ≠ `WAITING`/`TIMED_WAITING`: `BLOCKED` means waiting to *enter* a `synchronized`/lock; `WAITING` usually means `Object.wait()`/`park()` (a condition, not raw contention). Limitation: a dump is a single instant — it shows contention only if you happen to catch it. Several dumps showing the same hot monitor is strong evidence. ## Signal 2 — Java Flight Recorder (JFR) — the quantified view JFR is a low-overhead, built-in event recorder. Start it with `jcmd <pid> JFR.start` or `-XX:StartFlightRecording`. Relevant events: - **`jdk.JavaMonitorEnter`** ('Java Monitor Blocked') — fired when a thread blocks entering a monitor; carries the **monitored class**, the **blocking duration**, and a **stack trace**. - **`jdk.JavaMonitorWait`** — `Object.wait()` episodes. - **`jdk.ThreadPark`** — `LockSupport.park` (used by `ReentrantLock`, queues), so it also covers `java.util.concurrent` locks. Open the recording in **JDK Mission Control**, go to the lock/contention view, and **sort by aggregate blocked time** — the top entry is your hottest lock with the exact contended type and call site. This turns 'something is slow' into 'this specific monitor cost 4.2s of blocked time across 50k events.' ## Signal 3 — async-profiler lock mode `async-profiler -e lock` samples contended-lock acquisitions and produces a **flame graph weighted by contention time**. The widest frames are the call sites where threads wait the most — extremely direct for locating the offending code. ## Signal 4 — Benchmarks (JMH) for design comparison When choosing between designs (e.g. `synchronized` counter vs `AtomicLong` vs `LongAdder`, or coarse vs striped), a **JMH** benchmark run at varying thread counts shows how each scales. This is how you *prove* `LongAdder` wins under high write contention before changing production code. ## Signal 5 — OS / JVM symptoms - High **involuntary context switches** (`pidstat -w`, `vmstat`) — threads being parked/unparked fighting over locks. - **CPU below saturation while throughput is flat and a work queue is backing up** — classic 'serialized behind a lock' shape: you have work and cores but can't use them. - Throughput that **drops** as you add threads (negative scaling) is a strong contention tell. ## The workflow 1. **Confirm** with thread dumps (cheap, immediate) — is anything BLOCKED, and on what? 2. **Quantify** with JFR (which lock, how much total blocked time) or async-profiler (which call site). 3. **Fix** the single hottest lock (narrow the section / split / go lock-free). 4. **Re-measure** — contention often just moves to the next lock; iterate. Measure, fix the top offender, re-measure: contention optimization is iterative because relieving one bottleneck exposes the next.