JVM / GC Overview
Understand heap behavior and pause trade-offs before tuning flags.
📌 Key IdeaGC is a throughput-vs-latency trade-off system. Start with sane defaults (G1 in modern JVMs), observe allocation rate/pause metrics, then tune only when data shows pressure.
Why It Matters
- Java memory management is automatic, but not free; bad allocation patterns still hurt latency.
- Interviewers expect collector selection rationale (latency vs throughput), not only flag memorization.
Visual
♻️ Heap + GC pause intuition
Heap regions: Young -> Old Most objects die young -> frequent cheap young collections Long-lived objects -> promoted to old regions Goal: keep allocation fast keep pause times within SLO
When to Use
- Performance rounds asking about pause spikes and memory pressure.
- Services with high allocation churn or latency SLO violations.
When NOT to Use
- Premature flag tweaking without metrics/baselines.
- Assuming GC is root cause before profiling app hotspots.
Different garbage collectors (high level)
| Aspect | G1 | ZGC / Shenandoah | Parallel GC |
|---|---|---|---|
| Primary goal | Balanced latency + throughput | Very low pause latency | Max throughput |
| Typical fit | General server default | Latency-critical services | Batch/compute jobs |
| Trade-off | Moderate complexity | Higher memory/overhead considerations | Longer pauses possible |
Interview Q&A
Quick Cheat Sheet
Start pointUse modern default collector + observability.
Top smellFrequent full GC or pause spikes near traffic peaks.
RuleMeasure first, tune second.