An app is slow and you suspect GC. Using jstat alone, how do you confirm GC churn or a heap leak, and what are jstat's limits here?

## Diagnosing GC trouble with jstat — and where it stops When an app is sluggish and you suspect garbage collection, jstat is the cheapest confirmation step. But it's important to know exactly what it *can* prove and what it *can't*. ### Step 1 — sample over time, not once The GC counters (YGC, FGC, YGCT, FGCT, GCT) are **cumulative since JVM start**, so a single snapshot is nearly useless. Poll: ``` jstat -gcutil <pid> 1000 ``` and watch *deltas* across many lines. A 1-second interval is a good default for human watching. ### Step 2 — read the three diagnostic signals 1. **Full-GC frequency (FGC delta).** If FGC increments several times per second, the collector is repeatedly doing the expensive, often stop-the-world major collection. Frequent full GCs almost always correlate with latency spikes. 2. **GC overhead (GCT vs elapsed).** Take GCT (total GC seconds) and divide by the process's elapsed wall-clock time (from `jstat -t` which prepends a Timestamp column, or the OS). A healthy server spends a low single-digit percentage in GC; tens of percent means GC is your bottleneck. This is essentially the same condition the JVM itself watches for `GC overhead limit exceeded` (≈98% time in GC reclaiming <2%). 3. **The leak shape — Old not falling.** This is the decisive one. Watch **O** immediately *after* each full GC (FGC ticks up). - If O **drops back down** after a full GC and the app stabilizes → not a leak; it's transient pressure / undersized heap / a burst of allocation. - If O **stays high / ratchets upward** after every full GC, climbing toward 100% over minutes → live (reachable) data keeps growing. The collector ran but had nothing it was *allowed* to reclaim. That is the signature of a **heap leak**, heading for `OutOfMemoryError: Java heap space`. The same logic applies to **M** (metaspace) climbing toward its max → a likely **classloader leak** ending in `OutOfMemoryError: Metaspace`. ### Step 3 — distinguish leak vs. mere pressure The jstat output lets you separate two commonly-confused situations: - **Undersized heap / high allocation rate:** lots of GCs, but Old *recovers* after each full GC. Remediation: bigger `-Xmx`, reduce allocation, tune the collector. - **Leak:** Old never recovers. Remediation: find what's retaining objects — and a bigger heap only delays the OOM. ### Where jstat hits its ceiling jstat reports **aggregate counters only**. It will tell you *that* the old gen is full and *that* full GCs aren't reclaiming it — but it cannot tell you **which classes, which objects, or which allocation sites** are responsible. It has no per-object, per-thread, or per-stack-trace detail. So once jstat has confirmed the symptom, you escalate to tools that show the *cause*: - **Heap dump** via `jmap -dump:live,format=b,file=heap.hprof <pid>` (or `-XX:+HeapDumpOnOutOfMemoryError` to capture one automatically at the crash), then analyze with **Eclipse MAT** or **VisualVM** to find **dominator trees** and **retained sizes** — i.e., *what* is holding memory and *who* keeps it reachable. - **GC logs** (`-Xlog:gc*` on modern JVMs) for a complete, timestamped history with pause durations and causes — richer and more permanent than jstat sampling. - **Java Flight Recorder (JFR)** / async-profiler for allocation profiling — *where in the code* the allocations originate. Other practical limits of jstat: it samples the perfdata file so it can miss very short-lived spikes between samples; it's a manual, interactive tool not a metrics pipeline (for fleets you want GC logs or a metrics agent feeding a dashboard); and it shows the JVM's view, not OS-level RSS, so native-memory issues outside the Java heap won't appear. ### Summary jstat is the **stethoscope**: cheaply confirm GC churn (FGC/FGCT growth, high GC overhead) and the **leak shape** (Old refusing to fall after full GCs). It's the wrong tool to identify the offending objects — for that you take a heap dump and open it in MAT, or capture GC logs / a JFR recording. Use jstat to decide *whether* to dig, then dig with the heavier tools.