Garbage Collection

Most objects die young — the weak generational hypothesis. The young gen (eden and two survivor spaces) is swept by frequent minor GCs that copy the few survivors; those are promoted to the old gen, collected rarely but expensively.

Garbage collection is the JVM automatically reclaiming heap objects that are no longer reachable from any live reference. It frees the developer from manual memory management — there is no free or delete — which prevents most leaks and dangling pointers. The trade-off is that collection timing is non-deterministic: you cannot predict exactly when an object is reclaimed.

The static final map is a GC root holding a strong reference to every Session ever parsed, so no entry ever becomes unreachable and the collector cannot reclaim it — a leak by reachability, not a GC bug. Fix it by bounding the cache: an LRU via LinkedHashMap.removeEldestEntry, or a WeakHashMap whose entries clear once no strong reference to the key remains.

A strong reference — the default — keeps its object reachable and blocks collection. A SoftReference is cleared only under memory pressure, so it fits memory-sensitive caches. A WeakReference is cleared at the next GC once no strong reference remains, as with WeakHashMap keys. A PhantomReference is never followable (get() always returns null); it only enqueues on a ReferenceQueue after collection, a safe post-mortem cleanup hook replacing finalize().

No — System.gc() is only a suggestion. The JVM may ignore it, and -XX:+DisableExplicitGC makes it a no-op. Calling it in app code typically forces an expensive full GC that hurts throughput; it does not free memory or fix a leak.

Old-gen occupancy O stays above 97% and never drops after a full GC, while FGC and FGCT climb steeply — back-to-back full collections that reclaim almost nothing. That is the signature of a retained live set (a leak), not of an undersized young generation. Confirm with a heap dump (jmap -dump) read in Eclipse MAT or VisualVM, whose dominator tree names the retaining GC root, plus -Xlog:gc* or JFR for the pause history.

Serial uses one thread, fine for small heaps. Parallel uses many threads to maximize throughput. CMS was concurrent but is now removed. G1 (garbage-first) is the default — region-based, balancing throughput against predictable pauses. ZGC and Shenandoah target very low, heap-size-independent pause times. The core trade-off is throughput versus pause time: more concurrent collectors cut pauses at some throughput cost.

ZGC does marking, relocation, and reference remapping concurrently with the running application. Coloured pointers keep GC state in unused address bits, and a load barrier on every reference read lazily remaps a stale pointer. Only brief root scans are stop-the-world, so pause time tracks the root-set size, not the heap size.

G1 Humongous Allocation marks objects larger than half a region: they are allocated straight into the old gen and collected poorly. They fragment the heap until evacuation has no free region left (To-space exhausted), so G1 falls back to a full stop-the-world compaction — the multi-second pauses. No pause-time goal can survive a fallback full GC. Fix the allocation itself, enlarge -XX:G1HeapRegionSize, and lower InitiatingHeapOccupancyPercent so the concurrent cycle starts earlier.

The histogram shows AuditEntry — and the byte[]/String it retains — growing without bound in lockstep with request volume, held through HashMap$Node. The audit bean accumulates one entry per request and never evicts. A Spring singleton bean lives as long as the application context, so everything it collects stays reachable and the GC is correct not to free it. Confirm the retaining path in a heap dump's dominator tree, then bound the buffer with a fixed size or an eviction policy.