The False Security of Automatic Garbage Collection

A memory leak in C++ is a 'whoops, forgot to free'. A memory leak in a garbage-collected language is an existential crisis about who holds a reference to whom, and why your application suddenly needs 32GB of RAM to display 'Hello World'

Nothing shatters your faith in “managed” runtimes like a Full GC pause that frees zero bytes because a singleton cache and one forgotten CompletableFuture are still lovingly holding half the heap hostage

After 15 years of tuning JVM heap sizes and GC flags, you realize the real memory leak was the friends you lost during those 3am incidents when the G1GC decided your 99th percentile latency targets were merely suggestions

The seasoned architect's dilemma: You escape manual memory management only to discover that automatic garbage collection means you've traded segfaults for unpredictable 200ms GC pauses during your 99th percentile latency measurements. Now you're profiling heap dumps at 3 AM, hunting for that one event listener that's keeping 2GB of DOM nodes alive, realizing that 'automatic' just means the pain is more subtle and the debugging requires a PhD in GC internals

GC collects unreachable objects; our leaks are perfectly reachable - through singletons, the event bus, and that “just cache it” map with no eviction

GC prevents you from forgetting to free, not from deciding to keep - your “temporary” LRU cache, global event bus, and unbounded subscription will dutifully retain 4 GB until the OOM killer writes the postmortem at 3 a.m

GC: Prevents leaks, delivers latency spikes - because predictable OOM beats random hangs