GC overhead limit exceeded

An OutOfMemoryError raised when the JVM spends nearly all its time in GC and recovers almost nothing.

Parallel GC raises java.lang.OutOfMemoryError: GC overhead limit exceeded when more than 98 percent of the time is spent in GC and less than 2 percent of the heap is recovered, over several consecutive full collections (-XX:+UseGCOverheadLimit, on by default). It is a symptom, not a cause: the live data set is larger than the heap, or a leak keeps filling it.

Look in the log for back-to-back Pause Full lines that reclaim almost nothing, then analyze a heap dump (jcmd GC.heap_dump) to find who retains the memory. Raising -Xmx postpones the failure but does not fix a leak.

Official documentation: Troubleshoot Memory Leaks (Oracle)

Throughput

The share of time the application spends on useful work rather than in GC pauses.

A throughput of 99 percent means one second of pauses per 100 seconds. Throughput-oriented tuning (Parallel, large heaps) accepts longer and rarer pauses. Latency-oriented tuning (ZGC, Shenandoah, G1 with a low pause goal) accepts more frequent, shorter work and spends more CPU in the collector.

GC Doctor computes throughput from the pauses of the selected range. It ignores concurrent work, which consumes CPU without stopping the application, so read it together with the CPU view.

Full GC

A stop-the-world collection of the entire heap: mark, then compact. The slowest collection; in a healthy application it is rare or absent.

Typical triggers: no room to promote or allocate after a young collection (Allocation Failure), an explicit System.gc() call, the metaspace threshold, a heap inspection or heap dump request, a concurrent collector that fell behind. The cost grows with the live data, since all of it must be marked and moved: seconds on a multi-gigabyte heap.

Serial and Parallel collect their old generation with a full collection by design. G1 uses a parallel full collection since JDK 10, but it remains a last resort. The sign of a problem is frequent full collections that reclaim little: the live data set is close to the heap size, and the application either leaks memory or is under-provisioned. Read the cause in the log line, Pause Full (cause), then the heap after the collection. GC Doctor lists every full GC with its cause and its heap before and after.