Garbage Collection

Java's garbage collector automatically reclaims memory occupied by objects no longer reachable by the running program, freeing developers from manual memory management while leaving resource cleanup to them.

Garbage collection (GC) is the JVM's automatic mechanism for reclaiming heap memory occupied by objects the program can no longer reach. Rather than requiring explicit free()/delete calls as in C/C++, Java's runtime periodically identifies unreachable objects and reclaims their memory. The Java Language Specification guarantees that GC happens conceptually, but leaves the exact algorithm, timing, and heap organization entirely up to each JVM implementation.

Automatic Memory Management

In manually-managed languages, forgetting to free memory causes leaks, and freeing memory still in use causes crashes or corruption. Java's garbage collector removes this class of bugs for memory (not for other resources) by tracking which objects are still reachable and automatically reclaiming the memory of everything that isn't, without the programmer ever calling a 'free' function.

void process() {
    byte[] buffer = new byte[1_000_000]; // allocated on the heap
    // ... use buffer ...
} // buffer goes out of scope; its memory becomes eligible for automatic reclamation
// No explicit free(buffer) call exists or is needed in Java.

Reachability and GC Eligibility

An object becomes eligible for garbage collection once it is unreachable — no chain of references from any GC root (active local variables, static fields, and similar roots) reaches it. Becoming eligible does not mean immediate collection; the JVM decides when, if ever before shutdown, to actually reclaim that memory.

This 'eligible vs. actually collected' distinction is central: correct Java code must never depend on exactly when an object's memory is reclaimed.

Collectors at a Conceptual Level

A garbage collector typically works by tracing: starting from GC roots, it walks the reference graph, marking everything reachable as live, and treating everything else as garbage to reclaim. Different collector algorithms vary in how they do the tracing, how they reclaim space, and how much they pause the application — but the fundamental reachability concept is the same across nearly all mainstream Java collectors.

HotSpot (the reference JVM implementation) has shipped several collectors over the years — Serial, Parallel, CMS (removed), G1 (default since Java 9), and newer low-pause collectors like ZGC and Shenandoah. Which collector is used, and its exact internal algorithm, is a JVM implementation choice, not something the Java language specifies.

Stop-the-World Concept

Many collection phases, in many collectors, require pausing all application threads briefly so the collector can safely inspect and move objects without the program changing the reference graph mid-analysis — this is commonly called a 'stop-the-world' pause. Older or simpler collectors tend to have longer, more noticeable pauses; modern low-pause collectors work hard to minimize stop-the-world time, sometimes down to sub-millisecond target pauses, but some brief synchronization is typically still involved.

The existence, frequency, and length of stop-the-world pauses is a JVM/collector implementation detail — the Java language itself makes no promise about pause behavior.

Concurrent Collection Concept

To reduce pause times, modern collectors do much of their marking and reclamation work concurrently with the running application, rather than stopping it entirely for the whole cycle. This adds complexity (the collector must handle the application mutating references while it's scanning) but can dramatically shorten stop-the-world pauses compared to older, fully stop-the-world designs.

Concurrent collection is a design strategy several modern HotSpot collectors (like G1, ZGC, Shenandoah) use to different degrees — the specifics are JVM-dependent, not part of the language.

Generational Collection Concept

Many collectors exploit the empirical observation that most objects die young: they organize the heap into generations (commonly a 'young' generation for newly-allocated objects and an 'old'/'tenured' generation for objects that have survived multiple collections). Young-generation collections happen frequently and are typically fast, since most objects there are already garbage; objects that survive enough young collections get promoted ('tenured') into the old generation, which is collected less often.

The exact generation names, sizes, and promotion thresholds vary by collector and JVM; some newer low-pause collectors deemphasize or restructure this generational split. Treat any specific diagram as illustrative, not a language guarantee.

Typical generational heap concept (JVM-dependent, not a language guarantee):

 [ Young Generation ]           [ Old / Tenured Generation ]
  Eden | S0 | S1        --->     long-lived, survived objects
  (frequent, fast GC)             (less frequent GC)

JVM-Specific Implementation Differences

The Java Language Specification requires that unreachable objects eventually become eligible for reclamation, but it does not mandate any specific algorithm, generational structure, pause behavior, or heap layout. Different JVM vendors (and even different collectors within the same JVM, selectable via flags) implement GC very differently, and can change their internals across versions without breaking language-level guarantees.

# Selecting a garbage collector (JVM flag - HotSpot example, implementation-specific)
java -XX:+UseG1GC MyApp
java -XX:+UseZGC MyApp
java -XX:+UseParallelGC MyApp

GC Does Not Replace Resource Management

Garbage collection only reclaims JVM-managed heap memory. It has no awareness of, and does nothing for, external resources an object might be holding — open files, sockets, database connections, native memory allocated outside the JVM heap, or locks. Those must be released explicitly, typically via AutoCloseable and try-with-resources; relying on GC (or worse, on finalize()) to release them risks resource exhaustion long before, or even without, any actual collection happening.

try (var conn = dataSource.getConnection()) {
    // use conn
} // connection released deterministically here - NOT dependent on garbage collection

Practical Usage: Working With, Not Against, the Collector

In practice, most Java code should simply not think about GC — avoid premature optimization like manually nulling every local variable. Where GC-related tuning genuinely matters (large heaps, latency-sensitive systems), it's addressed through JVM flags (heap size, collector choice, pause-time goals) and profiling, not by second-guessing the collector inside application code.

Edge Cases

System.gc() only suggests that the JVM run garbage collection — it is not a guarantee, and JVMs are free to ignore the request entirely. Also, OutOfMemoryError can still occur in a fully-functioning collector-managed heap: if too many objects remain genuinely reachable (a real leak via, say, an ever-growing static cache, or simply too much live data for the configured heap), the collector cannot free memory it correctly determines is still in use.

System.gc(); // a hint, not a command - JVM may ignore it entirely
// Reachable objects, even in an ever-growing collection, will still eventually
// exhaust the heap and throw OutOfMemoryError - GC cannot reclaim what is still reachable.

Mental Model

Picture the heap as a warehouse and the collector as an inventory auditor who periodically walks in from the loading-dock doors (GC roots) and tags everything reachable by walking connected paths (references). Anything left untagged after the walk is scrap, cleared out to make room. The auditor decides the schedule (timing is unspecified), and different warehouses (JVMs) may use entirely different auditing strategies (collector algorithms) — but the walk-and-tag concept, reachability, is universal.

Quick Reference

GC guarantees (JLS):    unreachable objects EVENTUALLY become eligible for reclamation
GC does NOT guarantee:  exact timing, exact algorithm, heap layout, pause behavior

Concepts (JVM-implementation-dependent specifics, not language rules):
  - stop-the-world pauses    - concurrent marking/collection
  - generational heaps        - collector choice (G1, ZGC, Shenandoah, Parallel, Serial, ...)

GC manages:      heap memory only
GC does NOT manage: files, sockets, connections, native memory, locks (-> use AutoCloseable)

Key Takeaways

Garbage collection automatically reclaims memory for objects that are no longer reachable, eliminating manual free/delete calls.

Becoming unreachable makes an object eligible for GC, not immediately collected - the JLS never specifies exact timing.

Stop-the-world pauses, concurrent collection, and generational heaps are common collector strategies, but their presence and details are JVM-implementation-dependent, not language guarantees.

Different JVMs and collectors (G1, ZGC, Shenandoah, Parallel, Serial) implement GC very differently while satisfying the same language-level reachability guarantee.

GC manages heap memory only - it never releases files, sockets, connections, or other external resources; those require explicit management via AutoCloseable and try-with-resources.

System.gc() is only a hint the JVM may ignore, and a fully-functioning collector can still throw OutOfMemoryError when live (reachable) data genuinely exceeds available heap.

System.gc(); // assumed to force immediate collection processLargeFile();

processLargeFile(); // just let the collector run on its own schedule

System.gc() is only a suggestion the JVM is free to ignore; code should never depend on it actually running or running at a specific time.

// Believing GC will eventually close this socket Socket s = new Socket(host, port); s = null;

try (Socket s = new Socket(host, port)) { // use s } // deterministically closed here

GC only reclaims heap memory - it never closes sockets, files, or other external resources. Use try-with-resources for anything holding an external resource.

// Assuming a specific collector or generational layout is guaranteed by the language // e.g. writing code that behaves differently based on assumed GC internals

// Treat GC algorithm, generations, and pause behavior as JVM implementation details; // write code that behaves correctly regardless of which collector runs it

The JLS guarantees only that unreachable objects eventually become eligible for collection - never write logic that depends on a specific collector's internal strategy.

What does the Java Language Specification actually guarantee about garbage collection?

Only that objects which become unreachable are eventually eligible for reclamation - it specifies no particular algorithm, timing, pause behavior, or heap organization; those are all JVM implementation choices.

Why is calling System.gc() not a reliable way to force collection?

System.gc() is merely a request/hint to the JVM to consider running garbage collection - the JVM is free to ignore it entirely, run it later, or do a partial collection, so code must never depend on it having any specific effect.

What is the empirical observation that motivates generational garbage collection?

Most objects die young - the vast majority of allocated objects become unreachable shortly after creation, so segregating a 'young' generation for frequent, cheap collection while rarely collecting long-lived ('old'/'tenured') objects is more efficient than treating the whole heap uniformly.

Can a fully correct, well-functioning garbage collector still cause an OutOfMemoryError? Explain.

Yes. If the program genuinely keeps too much data reachable at once (a real leak, or simply more live data than the configured heap allows), the collector correctly determines that data is still in use and cannot reclaim it, so the heap fills up and OutOfMemoryError is thrown regardless of how well the collector works.

What is a stop-the-world pause, and why do some collector phases require one?

A stop-the-world pause temporarily halts all application threads so the collector can safely inspect or move objects without the reference graph changing underneath it mid-analysis. Not every phase of every modern collector requires one, but some coordination point is typically still needed.

Why can two different JVMs (or two different collectors on the same JVM) behave very differently in terms of pause times and memory layout while both being fully spec-compliant?

Because the Java Language Specification only guarantees eventual reclamation of unreachable objects - it leaves the collection algorithm, heap structure, and pause strategy entirely up to the implementation, so vendors and collector designs are free to differ substantially.

Why doesn't garbage collection eliminate the need for try-with-resources when working with files or sockets?

GC reclaims only heap memory occupied by unreachable objects; it has no knowledge of, and takes no action on, external OS-level resources such as file descriptors or socket connections those objects might be holding - those must be released explicitly.

Does this loop necessarily cause an OutOfMemoryError? Why or why not?

Not necessarily. Each chunk becomes unreachable at the end of its loop iteration (no reference to it survives past that iteration), making it eligible for garbage collection. A functioning collector will typically reclaim these young, short-lived objects well before the heap fills, though the exact timing depends on the JVM's collector and heap configuration.

Write a short comment-only explanation (as a Java code comment block) of why relying on finalize() for releasing a database connection is unsafe, referencing GC eligibility versus actual collection timing.

// finalize() only runs (if at all) after the JVM decides to collect the object, // which happens at an unspecified time after the object becomes unreachable - // possibly never before the JVM exits. A connection 'cleaned up' only in finalize() // could stay open for an arbitrarily long time (or forever), exhausting the // connection pool well before any collection occurs. Use AutoCloseable + // try-with-resources instead for deterministic release.

The comment captures the core issue: GC eligibility (unreachable) and actual collection are decoupled in timing, and finalize() execution depends on collection actually happening - making it unsuitable for anything time-sensitive like releasing a pooled resource.

Will the garbage collector eventually free this memory? Explain.

No. Each byte[] added to the static list leak remains reachable through that static field for as long as the class is loaded - since nothing ever removes entries, the collector correctly identifies them as still in use and cannot reclaim them, leading to OutOfMemoryError given enough iterations. This is a genuine reachable-object leak, not something GC can fix.

Write two JVM command-line invocations that select different garbage collectors for the same program, illustrating that collector choice is a JVM configuration detail, not a language feature.

java -XX:+UseG1GC MyApp java -XX:+UseZGC MyApp Both invocations run the identical MyApp bytecode under Java's same reachability-based GC guarantee, but with different underlying collector algorithms and pause characteristics - demonstrating that collector choice is a JVM-level implementation detail selectable via flags, not something the Java language itself mandates.

void loop() {
    for (int i = 0; i < 1_000_000; i++) {
        byte[] chunk = new byte[1024];
        // chunk not stored anywhere else
    }
}

static List<byte[]> leak = new ArrayList<>();
void grow() {
    leak.add(new byte[1_000_000]);
}
// grow() called repeatedly in a loop