Common GC Failure Modes and How to Prevent Them

Promotion Storm
Promotion storm occurs when too many objects survive young generation collection and promote to old generation. Old generation fills rapidly, triggering frequent major GCs. Each major GC is slower than minor GC, causing latency spikes.
Common causes: large caches created at startup, connection pools, session state. These objects survive multiple minor GCs and promote. Once promoted, they stay until old gen fills. If the pattern repeats, old gen churns with premature promotions.
Memory Leaks in GC Languages
GC does not prevent all memory leaks. If your code holds references to objects it no longer needs, those objects are reachable and not collected. Event listeners not unregistered, cache entries without expiration, growing collections: all cause leaks despite GC.
Detect leaks by monitoring heap growth over time. If live data after GC increases steadily, you have a leak. Heap dumps identify what objects accumulate. The path to GC roots shows why they are retained.
Allocation Pressure
High allocation rate stresses GC. Allocating 1 GB per second means collecting 1 GB per second. Even fast minor GCs accumulate overhead. The GC cannot keep up and old generation fills from promoted survivors.
Reduce allocation pressure through object pooling for frequently allocated objects, avoiding unnecessary intermediate objects, and using primitive arrays instead of boxed collections. Profile allocation to find hot spots. Reducing allocation often improves performance more than GC tuning.
⚠️ Key Trade-off: Object pooling reduces allocation pressure but complicates code and risks pool exhaustion or leaks. Pool only for proven hot spots with measurable improvement. Premature pooling adds complexity without benefit.

💡 Key Takeaways

✓Promotion storm: too many survivors flood old generation, triggering frequent major GCs

✓GC languages can still leak: retained references prevent collection of unneeded objects

✓Monitor heap growth over time: steady increase in live data after GC indicates leak

✓High allocation pressure stresses GC: reduce allocation often beats tuning collector

✓Object pooling reduces pressure but adds complexity; pool only proven hot spots

📌 Interview Tips

1Explain promotion storm: caches and pools created at startup survive minor GCs and fill old gen

2When debugging memory growth in GC languages, take heap dumps and analyze retention paths to find leaks

3For allocation hot spots, recommend pooling or primitive arrays instead of boxed types to reduce GC pressure

← Back to Garbage Collection Fundamentals Overview