Garbage collection (GC) is the automatic process by which a runtime environment reclaims memory that a program has allocated but no longer needs. It eliminates the need for developers to manually free memory, reducing bugs like memory leaks and dangling pointers.
Garbage collection is a form of automatic memory management built into many modern runtimes and languages, including Java, Python, Go, and JavaScript. The garbage collector identifies objects in heap memory that are no longer reachable by the running program and reclaims that memory for future use. This contrasts with manual memory management (e.g., C's malloc/free), where the developer explicitly controls allocation and deallocation. The term 'garbage' refers to any allocated memory that can no longer be accessed through any live reference.
Without GC, developers must track every allocation and free it exactly once — freeing too early causes use-after-free bugs, and forgetting to free causes memory leaks that grow until the process crashes. GC largely eliminates these entire classes of bugs, dramatically improving developer productivity and program safety. It is especially important in long-running server applications where accumulated leaks can silently degrade performance over days or weeks.
The most common algorithm is mark-and-sweep: the GC starts from 'root' references (stack variables, globals) and marks every object reachable by following references, then sweeps through the heap to free unmarked objects. Reference counting (used in CPython and Swift) increments a counter when a reference is created and decrements it when removed, freeing the object when the count hits zero. Generational GC (used in the JVM, .NET, and V8) splits the heap into young and old generations, collecting short-lived objects in the cheaper young generation far more frequently than long-lived objects. Copying collectors compact live objects to eliminate heap fragmentation as a side effect of collection.
A stop-the-world pause halts all application threads while the GC runs, guaranteeing a consistent view of the heap but introducing latency spikes. Modern collectors like Go's tricolor concurrent mark-and-sweep and Java's ZGC or G1 perform most work concurrently alongside the application to minimize pause times. Concurrent GC requires additional bookkeeping (write barriers) to track references mutated while the collector is running. Choosing between throughput-optimized and latency-optimized GC settings is a key tuning decision for production systems.
A common misconception is that GC eliminates memory leaks entirely — it does not. Objects that are still referenced but logically no longer needed (e.g., items accumulating in a static list or a cache with no eviction policy) will never be collected because they remain reachable. These 'logical leaks' are just as harmful as traditional leaks and are often harder to diagnose. Always pair GC with deliberate reference lifecycle management, weak references for caches, and heap profiling tools.
Minimize object allocation in hot paths to reduce GC pressure — reuse objects or use object pools for frequently created short-lived instances. Prefer local variables over long-lived fields so objects become unreachable quickly and are collected in the cheap young generation. Use language-specific profilers (VisualVM for JVM, memory_profiler for Python, pprof for Go) to measure actual allocation rates and GC pause times rather than guessing. Tune GC parameters such as heap size and generation ratios only after profiling, as premature tuning based on assumptions often makes things worse.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app