What Triggers Young GC vs. Full GC in Java? Interview Guide

GC Types and Trigger Conditions

Young GC (Minor GC) – reclaims Eden + Survivor spaces. Triggered when a new object allocation cannot fit into Eden.

Full GC – reclaims the entire heap (young + old) and Metaspace. Triggered by any of the following conditions:

Old‑generation space shortage – objects that survive multiple Young GCs are promoted, large objects allocated directly to the old generation (via -XX:PretenureSizeThreshold), or memory leaks that fill the old generation.

Metaspace exhaustion – since JDK 8 Metaspace stores class metadata in native memory; heavy use of dynamic proxies, Groovy, CGLIB, etc., can fill Metaspace and cause a Full GC.

Allocation‑guarantee (space‑allocation guarantee) failure – before a Young GC the JVM checks whether the old generation has enough contiguous space for all objects that might be promoted. If the check fails, the JVM either “risks” promotion (which may lead to a Full GC) or performs a Full GC immediately. After JDK 6 u24 the rule simplifies: if the old‑gen free space exceeds the total size of live young‑gen objects (or the average size of previously promoted objects) the Young GC proceeds; otherwise a Full GC occurs. The flag -XX:-HandlePromotionFailure is ineffective in newer versions.

Explicit System.gc() call – most JVMs honor the request and perform a Full GC. The call can be disabled with -XX:+DisableExplicitGC, turning it into a no‑op.

Young GC Trigger Condition

The condition is singular: when a new object allocation cannot fit into Eden, a Young GC is triggered.

Important details:

Young GC actually collects the whole young generation (Eden + S0 + S1), but because Survivor spaces usually contain few objects, it feels like “Eden full”.

Survivor space becoming full does not independently trigger GC; it is merely a staging area during Young GC.

// Assume Eden size is 20 MB
byte[] arr1 = new byte[10 * 1024 * 1024]; // Eden left 10 MB
byte[] arr2 = new byte[10 * 1024 * 1024]; // Eden left 0 MB
byte[] arr3 = new byte[1 * 1024 * 1024];  // Allocation fails → triggers Young GC

The pseudo‑code illustrates the classic Young GC scenario: allocating arr3 fails because Eden is full, causing a GC.

Full GC Trigger Conditions

Old‑generation space shortage

Objects that survive many Young GCs are promoted to the old generation.

Large objects allocated directly to the old generation (size > -XX:PretenureSizeThreshold).

Memory leaks that prevent old‑generation objects from being reclaimed.

Metaspace exhaustion

Set a maximum Metaspace size, e.g., -XX:MaxMetaspaceSize=256m.

When many classes are loaded (dynamic proxies, Groovy scripts, CGLIB, etc.), Metaspace can fill up, triggering a Full GC to reclaim class metadata.

Allocation‑guarantee failure

Before Young GC, the JVM checks whether the old generation has enough contiguous space for all objects that might be promoted.

If sufficient, Young GC proceeds; otherwise the JVM decides whether to “risk” promotion.

Choosing to risk means hoping the actual promoted size is smaller; if the guess is wrong, a Full GC follows.

If risk is not allowed, a Full GC is performed immediately.

Explicit System.gc() call

Calling System.gc() or Runtime.getRuntime().gc() requests a Full GC.

Most JVMs honor it, causing a stop‑the‑world pause.

Production code should avoid it; disabling can be done with -XX:+DisableExplicitGC.

Allocation‑Guarantee Failure Details

JVM checks old‑gen free space before Young GC.

If enough, GC proceeds.

If not enough, the JVM may allow a “risk” promotion; a wrong guess leads to Full GC.

If risk is disallowed, Full GC is executed immediately.

Since JDK 6 Update 24 the rule is simplified: as long as the old‑gen has a contiguous region larger than the total size of live young‑gen objects (or larger than the average size of previously promoted objects), Young GC is allowed; otherwise a Full GC occurs.

Explicit System.gc()

Calling System.gc() or Runtime.getRuntime().gc() requests a Full GC. Most JVMs execute it, causing a full stop‑the‑world pause. Production code should avoid it; the effect can be disabled with -XX:+DisableExplicitGC, turning the call into a no‑op.

Metaspace Exhaustion

Configure the maximum Metaspace size, e.g., -XX:MaxMetaspaceSize=256m. When many classes are loaded (dynamic proxies, Groovy, CGLIB, etc.), Metaspace can become full, triggering a Full GC to reclaim class metadata.

Post‑Young GC Promotion Overflow

If, after a Young GC, the total size of objects promoted to the old generation exceeds the remaining old‑gen space, this is equivalent to “old‑gen insufficient” and triggers a Full GC.

Comparison of Young GC and Full GC

Reclaimed region : Young GC – young generation (Eden + S0 + S1); Full GC – entire heap + Metaspace.

Trigger condition : Young GC – Eden space insufficient; Full GC – old‑gen insufficient, Metaspace insufficient, allocation‑guarantee failure, System.gc(), etc.

Algorithm : Young GC – copying; Full GC – depends on collector (Mark‑Sweep / Mark‑Compact).

STW impact : Young GC – few ms to tens of ms; Full GC – hundreds of ms to several seconds.

Frequency : Young GC – very frequent (seconds apart); Full GC – should be rare (hours or never).

Impact : Young GC – usually invisible to users; Full GC – can cause timeouts or response jitter.

High‑Frequency Follow‑Up Questions

How to investigate frequent Full GC in production? Check GC logs for frequency and pause time, use jstat -gcutil to monitor region usage, dump the heap with jmap -dump:format=b,file=heap.hprof and analyze with MAT or VisualVM to locate large objects or memory leaks.

How to avoid Full GC? Increase young generation size, ensure Survivor spaces are large enough, track large object allocations, choose low‑pause collectors (e.g., G1, ZGC), disable explicit System.gc(), and fix memory leaks.

When does the CMS collector trigger Full GC? CMS normally collects only the old generation, but if a concurrent mode failure occurs (old‑gen runs out of space during concurrent collection), CMS falls back to Serial Old, causing a long Full GC pause.

Summary

Young GC is triggered solely by insufficient Eden space. Full GC has multiple triggers, the primary one being old‑generation shortage, followed by Metaspace exhaustion, allocation‑guarantee failure, and explicit System.gc() calls. Enumerating these conditions clearly and coupling them with concrete troubleshooting steps (GC logs, jstat, heap dumps) demonstrates a solid understanding of JVM GC behavior.