Understanding JVM Garbage Collection Mechanisms for Interviews

In a light‑hearted anecdote, a programmer admits to uploading a half‑finished project to GitHub that only contains a README.md and a todo.txt , illustrating the pressure to show code during interviews.

The author jokes that interviewees often claim their project is in a refactor phase or that they are considering design patterns such as Strategy + Chain of Responsibility, which can sound impressive to interviewers.

As a practical tip, the article suggests keeping the repository private and only sharing it after establishing a connection with the interviewer.

Interview Question: JVM Garbage Collection Mechanism

JVM garbage collection (GC) automatically reclaims heap memory occupied by objects that are no longer reachable, preventing memory leaks and OutOfMemoryError. Understanding GC requires knowing the heap layout and the collection logic.

The heap is divided into the Young Generation and the Old Generation. The Young Generation consists of the Eden space and two Survivor spaces (From and To). Objects are allocated in Eden, survive a few Minor GCs, and then may be promoted to the Old Generation.

GC determines whether an object is dead by checking reachability from GC Roots (e.g., thread stacks, static fields, native references). If an object cannot be reached from any root, it becomes eligible for reclamation.

Typical collector combinations are:

Young Generation: ParNew or the young part of G1

Old Generation: CMS or the old part of G1

When using G1, the heap is split into equal‑sized regions rather than traditional generations, allowing predictive pauses via options such as -XX:MaxGCPauseMillis=200 .

CMS (Concurrent Mark‑Sweep) performs an initial stop‑the‑world mark, then concurrent marking and sweeping, followed by a final stop‑the‑world remark, which can lead to “floating garbage” because objects continue to change during the concurrent phases.

Minor GC collects only the Young Generation and is cheap and frequent, whereas Full GC collects the entire heap (including the Old Generation and Metaspace) and incurs a stop‑the‑world pause; frequent Full GCs indicate possible memory leaks or overly rapid object aging.

Example code that quickly triggers a Minor GC:

public class GCTest {
    public static void main(String[] args) {
        // Simulate rapid object creation
        for (int i = 0; i < 10000; i++) {
            byte[] b = new byte[1024 * 100]; // 100KB per object
        }
    }
}

Run the program with the following JVM options to observe GC activity:

-XX:+PrintGCDetails -Xms10m -Xmx10m -Xmn5m

The -Xmn5m flag sets the Young Generation size to 5 MB, causing Eden to fill quickly, prompting Survivor transfers and eventual promotion to the Old Generation. When the Old Generation cannot accommodate more objects, a Full GC occurs.

Object promotion is not solely age‑based; if Survivor spaces are full or an object exceeds the PretenureSizeThreshold , it may be allocated directly in the Old Generation.

Interviewers may ask about the three‑color marking algorithm used by concurrent collectors (white = unprocessed, gray = pending, black = processed). This leads to discussion of the SATB (Snapshot‑At‑The‑Beginning) algorithm, which handles object‑graph changes during concurrent marking.

Finally, the article recommends using tools such as VisualVM, jstat, and GCLogAnalyzer to analyze GC logs and tune parameters based on real‑world workload characteristics rather than memorizing generic settings.