Garbage Collection

What is Garbage Collection?

Garbage Collection (GC) is the JVM's automatic memory management: it identifies heap objects no longer reachable by any live thread and reclaims their memory, without the developer explicitly freeing it. This eliminates an entire category of bugs that plague manually-managed languages.

// C/C++: manual management — forget this and you leak memory forever
int* ptr = (int*)malloc(sizeof(int));
*ptr = 42;
free(ptr);  // miss this line → memory leak. Use after free → undefined behaviour.

// Java: GC tracks reachability automatically
Person p = new Person("Alice");
// ... use p ...
p = null;  // no more references → eligible for collection
// GC reclaims it on its own schedule — you never call free()

This page assumes you already understand the generational heap (Young/Old generation, Eden, Survivor spaces) and the major GC algorithms (G1, ZGC, Shenandoah) — those are covered in depth in JVM Internals. Here we go further: how references actually work, what "memory leak" means when there's no free(), and how to diagnose GC problems in a running system.

Reference Types — Controlling GC Eligibility

By default, every reference you create is a strong reference — as long as it exists, the object cannot be collected. Java's java.lang.ref package provides weaker reference types that let you hint the GC about how badly you need an object kept alive.

/*
 *  Reference strength (strongest to weakest):
 *
 *  STRONG     — normal references (Object o = new Object())
 *               Never collected while reachable. Default for everything.
 *
 *  SOFT       — collected only when the JVM is low on memory
 *               (right before OutOfMemoryError would otherwise be thrown)
 *               Use for: memory-sensitive caches
 *
 *  WEAK       — collected at the NEXT GC cycle, regardless of memory pressure
 *               Use for: canonical mappings, metadata that shouldn't keep
 *               its key alive (WeakHashMap)
 *
 *  PHANTOM    — already finalized; queue-only notification after collection
 *               Use for: cleanup actions when an object is actually freed
 *               (replaces deprecated finalize())
 */

WeakReference — the most common in practice

import java.lang.ref.*;

Person p = new Person("Alice");
WeakReference<Person> weakRef = new WeakReference<>(p);

p = null;          // remove the only strong reference
System.gc();   // (just for demonstration — never call this in real code)

weakRef.get();  // null — collected, because only a weak reference remained

// Real-world use: WeakHashMap — entries disappear when the KEY has no
// other strong references. Perfect for caches keyed by objects with
// their own lifecycle (e.g. listener registries keyed by component).
Map<Component, Listener> listeners = new WeakHashMap<>();
listeners.put(button, clickListener);
// When 'button' is no longer referenced elsewhere, this entry
// disappears automatically — no manual cleanup needed.

SoftReference — memory-sensitive caching

// Survives until the JVM is actually under memory pressure —
// effectively "keep this if you can afford it"
class ImageCache {
    private final Map<String, SoftReference<BufferedImage>> cache = new ConcurrentHashMap<>();

    public BufferedImage get(String path) {
        SoftReference<BufferedImage> ref = cache.get(path);
        BufferedImage img = (ref != null) ? ref.get() : null;
        if (img == null) {
            img = loadFromDisk(path);
            cache.put(path, new SoftReference<>(img));
        }
        return img;
    }
}
// In production: prefer Caffeine or Guava Cache — they offer size-based
// and time-based eviction with far more control than SoftReference alone.

PhantomReference — replacing finalize()

// finalize() is deprecated since Java 9 — unpredictable timing,
// can resurrect objects, adds GC overhead. Use Cleaner instead.

class NativeResource implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();
    private final Cleaner.Cleanable cleanable;
    private final long nativeHandle;

    NativeResource() {
        this.nativeHandle = allocateNative();
        // Register cleanup action — runs when 'this' becomes phantom reachable
        this.cleanable = cleaner.register(this, new CleanupAction(nativeHandle));
    }

    @Override
    public void close() { cleanable.clean(); }  // explicit, preferred path

    // Static nested class — must NOT hold a reference to the outer object,
    // or it would prevent collection entirely (defeats the purpose)
    private static class CleanupAction implements Runnable {
        private final long handle;
        CleanupAction(long handle) { this.handle = handle; }
        @Override public void run() { freeNative(handle); }  // fallback if close() never called
    }
}

Memory Leaks — Yes, They Happen With GC

A "leak" in Java doesn't mean forgotten free() calls — it means objects remain strongly reachable long after they're actually needed. The GC is doing its job correctly; your code is just keeping references alive unintentionally.

1. Static collections that only grow

// ❌ Static field is a GC root — anything in this list lives forever
public class RequestLog {
    private static final List<Request> log = new ArrayList<>();
    public static void record(Request r) { log.add(r); }  // never removed!
}

// ✅ Bounded cache with eviction
private static final Cache<String, Request> log = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofHours(1))
    .build();

2. Inner classes holding implicit outer references

// ❌ Non-static inner class holds an implicit reference to the outer instance.
// If this Listener outlives the Activity (Android-style leak, but applies
// anywhere a long-lived object holds a short-lived listener), the outer
// object can never be collected.
public class ReportGenerator {
    private byte[] hugeBuffer = new byte[100_000_000];  // 100MB

    class CompletionListener {  // non-static — implicitly holds ReportGenerator.this
        void onComplete() { ... }
    }
}
// eventBus.subscribe(reportGen.new CompletionListener());
// If eventBus lives forever, so does the 100MB buffer.

// ✅ Static nested class — no implicit outer reference
public class ReportGenerator {
    private static class CompletionListener {
        void onComplete() { ... }
    }
}

3. ThreadLocal not removed in pooled threads

// ❌ In a thread pool, threads are REUSED across requests.
// A ThreadLocal set during request A and not removed leaks into
// request B's thread — and worse, the value lives as long as the thread.
private static final ThreadLocal<UserContext> CONTEXT = new ThreadLocal<>();

void handleRequest(Request req) {
    CONTEXT.set(new UserContext(req.getUser()));
    process(req);
    // missing CONTEXT.remove() — thread pool reuses this thread forever
}

// ✅ Always remove in finally
void handleRequest(Request req) {
    try {
        CONTEXT.set(new UserContext(req.getUser()));
        process(req);
    } finally {
        CONTEXT.remove();  // critical in thread pools
    }
}

4. Unclosed resources and registered listeners

// ❌ Resources hold native handles — not cleaned by GC, leak file descriptors
FileInputStream fis = new FileInputStream("data.txt");
// never closed — leaks an OS file handle until GC finalizes it (unpredictable)

// ✅ try-with-resources guarantees close()
try (var fis = new FileInputStream("data.txt")) { ... }

// ❌ Listener registered on a long-lived publisher, never removed
eventBus.subscribe(this);  // keeps 'this' alive as long as eventBus exists

// ✅ Always unsubscribe
eventBus.unsubscribe(this);

Diagnosing GC Problems

Reading GC logs

# Enable structured GC logging (Java 9+ unified logging)
java -Xlog:gc*:file=gc.log:time,uptime,level,tags MyApp

# Example log line:
[2.341s][info][gc] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 512M->128M(2048M) 8.2ms
/*
 *  2.341s          — JVM uptime when this GC happened
 *  GC(12)          — 13th GC event since JVM start (0-indexed)
 *  Pause Young     — type: minor GC (Young Gen only)
 *  512M->128M      — heap usage before -> after this collection
 *  (2048M)         — total heap capacity
 *  8.2ms           — pause duration (the number that matters for latency)
 */

# What to watch for:
# - Frequent Full GC ("Pause Full") = old gen filling fast = possible leak
# - Growing "before" size over time across many GCs = leak signature
# - Pause times trending up = heap fragmentation or sizing issue

Heap dumps — finding the actual leak

# Capture a heap dump from a running JVM
jmap -dump:live,format=b,file=heap.hprof <pid>

# Or trigger automatically on OutOfMemoryError (always enable in production)
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps MyApp

# Analyse with Eclipse MAT (Memory Analyzer Tool) or VisualVM:
# 1. Open the .hprof file
# 2. Run "Leak Suspects Report" — MAT's heuristics often find it directly
# 3. Look at "Dominator Tree" — sorts objects by retained heap size
# 4. Check "Path to GC Root" on suspect objects — shows WHY it's still reachable

# Quick live stats without a full dump
jstat -gc <pid> 1000        # GC stats every 1000ms
jcmd <pid> GC.heap_info     # current heap summary
jcmd <pid> VM.native_memory # native memory breakdown (needs -XX:NativeMemoryTracking=summary)

Comparing two heap dumps — the leak-hunting technique

/*
 *  The most reliable way to find a leak: take two heap dumps under
 *  load, separated by time, and compare object counts.
 *
 *  1. jmap -dump:live,file=before.hprof 
 *  2. Let the app run under normal load for 30+ minutes
 *  3. jmap -dump:live,file=after.hprof 
 *  4. Open both in Eclipse MAT, use "Compare" feature
 *
 *  Classes whose instance count grew disproportionately to traffic
 *  are your leak suspects. A healthy app's object counts should be
 *  roughly stable under steady-state load — growth = leak.
 */

Writing GC-Friendly Code

// ❌ String concatenation in a loop — creates N intermediate objects
String result = "";
for (int i = 0; i < 10_000; i++) result += i;

// ✅ StringBuilder — single mutable buffer
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10_000; i++) sb.append(i);

// ❌ Autoboxing in hot loops — allocates a wrapper object every iteration
Long sum = 0L;
for (long i = 0; i < 10_000_000; i++) sum += i;  // box, unbox, box...

// ✅ Primitive accumulator — zero allocation
long sum = 0;
for (long i = 0; i < 10_000_000; i++) sum += i;

// ✅ Object pooling — ONLY for genuinely expensive objects
// (DB connections, thread pools). NOT for ordinary objects —
// modern generational GC handles short-lived objects extremely cheaply,
// and pooling adds complexity and potential for stale state bugs.

Interview Questions