Full GC vs Minor GC vs Major GC — Semantics and Log Diagnosis

Q: Full GC vs Minor GC vs Major GC — Semantics and Log Diagnosis

**Minor GC** reclaims only the **young generation** (Eden + Survivors) — short pauses, triggered when Eden fills. **Full GC** (major GC) typically collects the **entire heap** including old gen — longer stop-the-world pauses. In logs, look for **GC pause** vs **Full GC** / **Pause Full**; frequent full GC usually signals heap pressure, promotion failure, or metaspace issues.

Intermediate·2 min read·

OracleNetflixAtlassianClouderaUber

Fast recall

Quick revision

Core answer

Minor GC reclaims only the young generation (Eden + Survivors) — short pauses, triggered when Eden fills. Full GC (major GC) typically collects the entire heap including old gen — longer stop-the-world pauses. In logs, look for GC pause vs Full GC / Pause Full; frequent full GC usually signals heap pressure, promotion failure, or metaspace issues.

Interview-ready guide

Interview answer

Java garbage collection events fall into three categories, and being able to distinguish them in logs is essential for diagnosing production performance problems.

Minor GC:

Collects the young generation — Eden plus the active Survivor space
Typically 10-50ms — normal and expected; happens every few seconds in busy apps
Triggered when Eden fills
Log marker in Java 9+: Pause Young (Normal)

Major GC (or Mixed GC in G1):

Targets the old generation
In G1, it's incremental — Pause Mixed collects young gen plus a few old-gen regions per cycle
Pause typically 50-200ms — within G1's -XX:MaxGCPauseMillis target
Triggered by old-gen occupancy heuristics

Full GC:

Collects the entire heap — young, old, and Metaspace
Stops all application threads — pauses can take seconds on large heaps
Causes visible p99 latency spikes and can trigger false-positive failure detection in distributed systems
Log marker: Pause Full with a reason in parentheses

Common full GC triggers and mitigations:

Explicit System.gc() from libraries — use -XX:+DisableExplicitGC
Promotion failure or to-space exhausted in G1 — increase heap or G1ReservePercent
Metaspace OOM — bound it with -XX:MaxMetaspaceSize and fix the ClassLoader leak
Genuine memory leak — capture a heap dump with -XX:+HeapDumpOnOutOfMemoryError and analyze in Eclipse MAT

The diagnostic discipline:

Always enable GC logging in production: -Xlog:gc* on Java 9+
Treat minor GC as background noise; investigate every full GC
Use GCEasy or Mission Control for visual analysis
Pair GC logging with heap dump on OOM so you have the snapshot when things go wrong

In an interview, I'd emphasize that knowing how to read a GC log is more practical than memorizing GC algorithm internals — the log tells you what is actually happening in production.

03 · Deep dive