Garbage Collection in Java

Garbage Collection (GC) is one of the most critical topics for FAANG interviews. It separates engineers who can merely write Java from those who can diagnose production outages, tune JVM performance, and make informed decisions about memory-intensive systems. Understanding GC internals is essential for system design discussions involving latency SLAs, throughput requirements, and capacity planning.

Why Garbage Collection? The Case Against Manual Memory Management

In C/C++, developers must explicitly allocate and free memory (malloc/free, new/delete). This leads to:

• Memory leaks — forgetting to free memory
• Dangling pointers — using memory after it's freed
• Double-free bugs — freeing memory twice (crashes, security vulnerabilities)

Java's GC eliminates these classes of bugs entirely by automatically reclaiming memory that is no longer reachable from the application's root references (stack variables, static fields, JNI references).

public void processOrder(Order order) {
    // temp object created on the heap
    OrderValidator validator = new OrderValidator(order);
    validator.validate();
    // After this method returns, 'validator' has no references
    // GC will reclaim it — no manual free() needed
}

Key principles:

• Live object = reachable from a GC root (referenced directly or transitively)
• Dead object = unreachable from any GC root
• GC runs on a daemon thread — you cannot force it (System.gc() is only a hint)
• When the heap is full and GC cannot reclaim enough space: java.lang.OutOfMemoryError: Java heap space

JVM Heap Structure

The JVM divides the heap into generations based on object age. This design exploits the Generational Hypothesis: most objects die young.

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Young["Young Generation"]
        direction LR
        Eden["Eden Space<br/>(new objects)"]
        S0["S0 (From)"]
        S1["S1 (To)"]
    end
    subgraph Old["Old Generation"]
        Tenured["Tenured Space<br/>(long-lived)"]
    end
    subgraph OffHeap["Off-Heap"]
        Meta["Metaspace<br/>(class metadata)"]
    end

    Eden -->|"Minor GC<br/>survivors"| S0
    S0 <-->|"Swap each cycle"| S1
    S1 -->|"Promote<br/>(age > 15)"| Tenured

    style Eden fill:#DBEAFE,stroke:#93C5FD,color:#1E40AF
    style S0 fill:#FEF3C7,stroke:#FCD34D,color:#92400E
    style S1 fill:#FEE2E2,stroke:#FCA5A5,color:#991B1B
    style Tenured fill:#E9D5FF,stroke:#A78BFA,color:#5B21B6
    style Meta fill:#D1FAE5,stroke:#6EE7B7,color:#065F46

The Generational Hypothesis

The entire design of generational GC rests on two empirical observations:

1. Most objects die young — temporary variables, iterators, intermediate results, request-scoped objects
2. References from old objects to young objects are rare — tracked via a "card table" or "remembered set"

This means focusing GC effort on the Young Generation (where most garbage is) gives the best return on investment. Collecting the entire heap every time would be extremely expensive.

Object Survival Rate
│
│  ████
│  ████
│  ████
│  ████░░
│  ████░░░░
│  ████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
│  ████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
└──────────────────────────────────────────────────── Object Age
   young                                        old

   ████ = objects that die (majority — collected cheaply)
   ░░░░ = objects that survive (minority — promoted)

GC Process: Mark, Sweep, Compact

All GC algorithms share a fundamental three-phase approach:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    A["1. MARK<br/>Traverse from GC roots,<br/>mark reachable objects"] --> B["2. SWEEP<br/>Reclaim memory of<br/>unmarked objects"]
    B --> C["3. COMPACT<br/>Defragment by moving<br/>live objects together"]

    style A fill:#DBEAFE,stroke:#93C5FD,color:#1E40AF
    style B fill:#D1FAE5,stroke:#6EE7B7,color:#065F46
    style r fill:#FEF3C7,stroke:#FCD34D,color:#92400E
    style s fill:#FEE2E2,stroke:#FCA5A5,color:#991B1B

BEFORE GC — A,C,E are live; B,D,F are garbage:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    B1A["A"]:::live --- B1B["B"]:::dead --- B1C["C"]:::live --- B1D["D"]:::dead --- B1E["E"]:::live --- B1F["F"]:::dead
    classDef live fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef dead fill:#FEE2E2,stroke:#EF4444,color:#991B1B

AFTER MARK — reachable objects marked:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    M2A["A ✓"]:::marked --- M2B["B"]:::dead --- M2C["C ✓"]:::marked --- M2D["D"]:::dead --- M2E["E ✓"]:::marked --- M2F["F"]:::dead
    classDef marked fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    classDef dead fill:#FEE2E2,stroke:#EF4444,color:#991B1B

AFTER SWEEP — garbage reclaimed, memory fragmented:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    S3A["A"]:::live --- S3x1[" "]:::free --- S3C["C"]:::live --- S3x2[" "]:::free --- S3E["E"]:::live --- S3x3[" "]:::free
    classDef live fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef free fill:#F9FAFB,stroke:#D1D5DB,color:#D1D5DB

AFTER COMPACT — live objects moved together, contiguous free space:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    C4A["A"]:::live --- C4C["C"]:::live --- C4E["E"]:::live --- C4x1[" "]:::free --- C4x2[" "]:::free --- C4x3[" "]:::free
    classDef live fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef free fill:#F9FAFB,stroke:#D1D5DB,color:#D1D5DB

GC Roots (starting points for the mark phase):

• Local variables on thread stacks
• Active threads themselves
• Static fields of loaded classes
• JNI references

Minor GC vs Major GC vs Full GC

Object Lifecycle Through GC

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
sequenceDiagram
    participant App as Application
    participant Eden as Eden Space
    participant S0 as Survivor S0
    participant S1 as Survivor S1
    participant Old as Old Generation

    App->>Eden: new Object()
    Note over Eden: Eden fills up
    Eden->>S0: Minor GC — survivors move to S0 (age=1)
    Note over Eden: Eden cleared
    App->>Eden: new Object()
    Note over Eden: Eden fills up again
    Eden->>S1: Minor GC — Eden survivors to S1
    S0->>S1: S0 survivors to S1 (age incremented)
    Note over S0: S0 cleared
    Note over S1: Objects with age > 15
    S1->>Old: Promotion to Old Gen

Promotion threshold: Objects that survive 15 Minor GC cycles (default, tunable with -XX:MaxTenuringThreshold) are promoted to Old Generation.

Eden → S0 → S1 → Old Gen: Step-by-Step

Step 1: New objects allocated in Eden

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Eden["Eden Space"]
        A["A"] & B["B"] & C["C"] & D["D"] & E["E"] & F["F"] & G["G"] & H["H"]
    end
    subgraph S0["Survivor S0"]
        empty1["(empty)"]
    end
    subgraph S1["Survivor S1"]
        empty2["(empty)"]
    end
    subgraph Old["Old Generation"]
        empty3["(empty)"]
    end

    style Eden fill:#DBEAFE,stroke:#3B82F6
    style S0 fill:#FEF3C7,stroke:#F59E0B
    style S1 fill:#FEE2E2,stroke:#EF4444
    style Old fill:#E5E7EB,stroke:#6B7280

All new objects are allocated in Eden. S0, S1, and Old Gen are empty.

Step 2: Eden fills up → Minor GC #1

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Before["Before GC"]
        direction LR
        subgraph Eden1["Eden (FULL)"]
            A1["A"]:::live
            B1["B"]:::dead
            C1["C"]:::live
            D1["D"]:::dead
            E1["E"]:::dead
            F1["F"]:::live
            G1["G"]:::dead
            H1["H"]:::dead
        end
    end

    Before -->|"Minor GC #1"| After

    subgraph After["After GC"]
        direction LR
        subgraph Eden2["Eden (CLEARED)"]
            x1["(empty)"]
        end
        subgraph S0a["S0 (To)"]
            A2["A (age=1)"]:::promoted
            C2["C (age=1)"]:::promoted
            F2["F (age=1)"]:::promoted
        end
    end

    classDef live fill:#D1FAE5,stroke:#10B981
    classDef dead fill:#FEE2E2,stroke:#EF4444
    classDef promoted fill:#FEF3C7,stroke:#F59E0B

Dead objects (B,D,E,G,H) are swept. Survivors copied to S0 with age=1.

Step 3: New objects fill Eden → Minor GC #2

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Before2["Before GC #2"]
        direction LR
        subgraph Eden3["Eden (FULL)"]
            I1["I"]:::live
            J1["J"]:::dead
            K1["K"]:::live
            L1["L"]:::dead
            M1["M"]:::dead
        end
        subgraph S0b["S0 (From)"]
            A3["A (age=1)"]:::live
            C3["C (age=1)"]:::dead
            F3["F (age=1)"]:::live
        end
    end

    Before2 -->|"Minor GC #2"| After2

    subgraph After2["After GC #2"]
        direction LR
        subgraph Eden4["Eden (CLEARED)"]
            x2["(empty)"]
        end
        subgraph S0c["S0 (CLEARED)"]
            x3["(empty)"]
        end
        subgraph S1a["S1 (To)"]
            A4["A (age=2)"]:::old
            F4["F (age=2)"]:::old
            I2["I (age=1)"]:::promoted
            K2["K (age=1)"]:::promoted
        end
    end

    classDef live fill:#D1FAE5,stroke:#10B981
    classDef dead fill:#FEE2E2,stroke:#EF4444
    classDef promoted fill:#FEF3C7,stroke:#F59E0B
    classDef old fill:#DBEAFE,stroke:#3B82F6

S0 and S1 swap roles every cycle. ALL survivors move to the "To" space.

Step 4: After many cycles → Promotion to Old Gen

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Before3["Before GC — Object A has age=15"]
        direction LR
        subgraph S0d["S0 (From)"]
            A5["A (age=15)"]:::promote
            X1["X (age=3)"]:::live
            Y1["Y (age=1)"]:::live
        end
    end

    Before3 -->|"Minor GC"| After3

    subgraph After3["After GC"]
        direction LR
        subgraph S1b["S1 (To)"]
            X2a["X (age=4)"]:::promoted
            Y2a["Y (age=2)"]:::promoted
        end
        subgraph OldGen["Old Generation"]
            A6["A (tenured)"]:::tenured
        end
    end

    classDef promote fill:#FDE68A,stroke:#D97706
    classDef live fill:#D1FAE5,stroke:#10B981
    classDef promoted fill:#FEF3C7,stroke:#F59E0B
    classDef tenured fill:#C4B5FD,stroke:#7C3AED

Object A survived 15 GC cycles (MaxTenuringThreshold) → promoted to Old Generation permanently.

Key rules of Survivor spaces:

• One Survivor space is always empty (the "To" space)
• Survivors are copied between S0 and S1 every Minor GC (copying collector)
• The empty space becomes "To", the occupied space becomes "From"
• Objects too large for Survivor go directly to Old Gen ("premature promotion")

How Minor GC Works — Internal Mechanics

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    A["Eden Full"] --> B["STW Pause"]
    B --> C["Reachable?"]
    C -->|No| D["Discard"]
    C -->|Yes| E["Age ≥ 15?"]
    E -->|Yes| F["Promote to Old Gen"]
    E -->|No| G["Copy to Survivor"]
    D & F & G --> H["Clear Eden + From, Swap S0↔S1, Resume"]

    style B fill:#FEE2E2,stroke:#991B1B,color:#991B1B
    style D fill:#FEF3C7,stroke:#92400E,color:#92400E
    style F fill:#DBEAFE,stroke:#1E40AF,color:#1E40AF
    style H fill:#D1FAE5,stroke:#065F46,color:#065F46

GC Types — Visual Comparison

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px'}}}%%
gantt
    title GC Pause Behavior — Timeline Comparison
    dateFormat X
    axisFormat %s

    section Serial GC
    App Running           :done, 0, 3
    STW (1 thread)        :crit, 3, 8
    App Running           :done, 8, 12

    section Parallel GC
    App Running           :done, 0, 3
    STW (N threads)       :crit, 3, 6
    App Running           :done, 6, 12

    section G1 GC
    App Running           :done, 0, 2
    Init Mark (STW)       :crit, 2, 3
    Concurrent Mark       :active, 3, 8
    Remark (STW)          :crit, 8, 9
    App Running           :done, 9, 12

    section ZGC
    App Running           :done, 0, 1
    Pause (<1ms)          :crit, 1, 1
    Concurrent (all work) :active, 1, 11
    Pause (<1ms)          :crit, 11, 11
    App Running           :done, 11, 12

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
quadrantChart
    title GC Collectors — Pause Time vs Throughput
    x-axis "Low Throughput" --> "High Throughput"
    y-axis "Low Pause (fast)" --> "High Pause (slow)"
    quadrant-1 "High pause, High throughput"
    quadrant-2 "High pause, Low throughput"
    quadrant-3 "Low pause, Low throughput"
    quadrant-4 "Low pause, High throughput"
    Serial GC: [0.25, 0.85]
    Parallel GC: [0.75, 0.70]
    G1 GC: [0.65, 0.35]
    ZGC: [0.60, 0.10]
    Shenandoah: [0.55, 0.12]

Evolution: Serial → Parallel → G1 → ZGC/Shenandoah = progressively lower pauses. Trade-off: lower pauses require more CPU for concurrent GC bookkeeping.

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TD
    subgraph "GC Selection Decision Tree"
        direction TB
        Q1["What's your heap size?"]
        Q1 -->|"< 100MB"| Serial["Serial GC<br/>-XX:+UseSerialGC"]
        Q1 -->|"100MB – 8GB"| Q2["What matters more?"]
        Q1 -->|"> 8GB"| Q3["Latency requirement?"]
        Q2 -->|"Throughput"| Parallel["Parallel GC<br/>-XX:+UseParallelGC"]
        Q2 -->|"Latency"| G1["G1 GC<br/>-XX:+UseG1GC"]
        Q3 -->|"P99 < 10ms"| ZGC["ZGC<br/>-XX:+UseZGC"]
        Q3 -->|"P99 < 200ms"| G1
        Q3 -->|"Red Hat"| Shen["Shenandoah<br/>-XX:+UseShenandoahGC"]
    end

    style Serial fill:#F3F4F6,stroke:#6B7280
    style Parallel fill:#DBEAFE,stroke:#3B82F6
    style G1 fill:#D1FAE5,stroke:#10B981
    style ZGC fill:#FEF3C7,stroke:#F59E0B
    style Shen fill:#FCE7F3,stroke:#EC4899

G1 GC Region Layout

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    E1["E"]:::eden --- E2["E"]:::eden --- S1["S"]:::surv --- O1["O"]:::old --- O2["O"]:::old --- H1["H"]:::humon --- H2["H"]:::humon --- O3["O"]:::old --- F1["-"]:::free --- E3["E"]:::eden

    classDef eden fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    classDef surv fill:#FEF3C7,stroke:#F59E0B,color:#92400E
    classDef old fill:#E5E7EB,stroke:#6B7280,color:#374151
    classDef humon fill:#FCE7F3,stroke:#EC4899,color:#9D174D
    classDef free fill:#FFFFFF,stroke:#D1D5DB,color:#9CA3AF

E = Eden | S = Survivor | O = Old | H = Humongous (>50% region) | - = Free

Regions are NOT contiguous by type. G1 picks regions with the MOST garbage to collect first — maximizes reclaimed space per pause.

ZGC — Colored Pointers

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    U["16 unused"]:::unused --> M0["M0"]:::mark --> R["Remap"]:::remap --> FN["Final"]:::final --> M1["M1"]:::mark --> ADDR["44-bit Address (16TB)"]:::addr

    classDef unused fill:#F3F4F6,stroke:#6B7280,color:#6B7280
    classDef mark fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF
    classDef remap fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef final fill:#FEF3C7,stroke:#F59E0B,color:#92400E
    classDef addr fill:#F5F3FF,stroke:#8B5CF6,color:#5B21B6

Load barrier: on every object reference load, checks color bits. If stale → self-heals the reference. No STW needed.

GC Algorithms

1. Serial GC

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Serial["Serial GC — Single Thread, Full STW"]
        direction LR
        A1["App Running"]:::app --> P1["⏸ STW Pause<br/>(1 GC thread)"]:::stw --> A2["App Running"]:::app
    end
    classDef app fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef stw fill:#FEE2E2,stroke:#EF4444,color:#991B1B

• Flag: -XX:+UseSerialGC
• Best for: Single-CPU, small heaps (<100MB), client apps
• Algorithm: Mark-Copy (Young) + Mark-Sweep-Compact (Old)

2. Parallel GC (Throughput Collector)

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Parallel["Parallel GC — N Threads, Full STW"]
        direction LR
        A1["App Running"]:::app --> P1["⏸ STW Pause<br/>(N GC threads in parallel)"]:::stw --> A2["App Running"]:::app
    end
    classDef app fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef stw fill:#FEE2E2,stroke:#EF4444,color:#991B1B

• Flag: -XX:+UseParallelGC (default Java 8)
• Best for: Batch processing, data pipelines, throughput > latency
• Tuning: -XX:ParallelGCThreads=N, -XX:GCTimeRatio=99

3. CMS (Concurrent Mark-Sweep) — Deprecated

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph CMS["CMS — Mostly Concurrent"]
        direction LR
        A1["App"]:::app --> IM["⏸ Init Mark<br/>(STW)"]:::stw --> CM["Concurrent<br/>Mark"]:::conc --> RM["⏸ Remark<br/>(STW)"]:::stw --> CS["Concurrent<br/>Sweep"]:::conc --> A2["App"]:::app
    end
    classDef app fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef stw fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    classDef conc fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF

• Flag: -XX:+UseConcMarkSweepGC (removed Java 14)
• Problems: No compaction → fragmentation, concurrent mode failure

4. G1 GC (Garbage-First) — Default Since Java 9

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph G1["G1 — Region-based, Predictable Pauses"]
        direction LR
        A1["App"]:::app --> YGC["⏸ Young GC<br/>(evacuate regions)"]:::stw --> A2["App"]:::app --> MIX["⏸ Mixed GC<br/>(Young + Old regions)"]:::stw --> A3["App"]:::app
    end
    classDef app fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef stw fill:#FEF3C7,stroke:#F59E0B,color:#92400E

• Flag: -XX:+UseG1GC (default Java 9+), -XX:MaxGCPauseMillis=200
• Key: Heap split into equal regions (E/S/O/H), collects regions with most garbage first
• Phases: Young-only → Space reclamation (mixed) → Full GC (rare fallback)

5. ZGC (Z Garbage Collector) — Ultra-Low Latency

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph ZGC["ZGC — Fully Concurrent, < 1ms Pauses"]
        direction LR
        A1["App"]:::app --> P1["⏸<br/>< 1ms"]:::stw --> CW["Concurrent relocation<br/>+ remapping"]:::conc --> P2["⏸<br/>< 1ms"]:::stw --> A2["App"]:::app
    end
    classDef app fill:#D1FAE5,stroke:#10B981,color:#065F46
    classDef stw fill:#FEE2E2,stroke:#EF4444,color:#991B1B
    classDef conc fill:#DBEAFE,stroke:#3B82F6,color:#1E40AF

• Flag: -XX:+UseZGC (production Java 15+, heaps 8MB–16TB)
• Key: Colored pointers, load barriers, concurrent compaction
• Best for: Trading systems, real-time services, large in-memory caches

6. Shenandoah GC

• Flag: -XX:+UseShenandoahGC (Java 12+, backported to 8/11)
• Key difference from ZGC: Brooks forwarding pointers (extra word per object). Works on 32-bit JVMs.
• Similar goals: Low pause, concurrent compaction. Developed by Red Hat.

GC Algorithm Comparison

GC Tuning: Key JVM Flags

Essential Flags

# Heap sizing
-Xms4g                         # Initial heap size (set equal to -Xmx to avoid resizing)
-Xmx4g                         # Maximum heap size

# GC algorithm selection
-XX:+UseG1GC                   # Use G1 (default in Java 9+)
-XX:+UseZGC                    # Use ZGC (Java 15+)
-XX:+UseParallelGC             # Use Parallel GC

# G1 tuning
-XX:MaxGCPauseMillis=200       # Target max pause (G1 will try to meet this)
-XX:G1HeapRegionSize=16m       # Region size (1MB-32MB, power of 2)
-XX:InitiatingHeapOccupancyPercent=45  # Start mixed GC when Old Gen is 45% full

# Generational tuning
-XX:NewRatio=2                 # Old:Young = 2:1 (Old Gen is 2/3 of heap)
-XX:SurvivorRatio=8            # Eden:Survivor = 8:1:1
-XX:MaxTenuringThreshold=15    # Promote to Old Gen after 15 cycles

# Metaspace
-XX:MetaspaceSize=256m         # Initial metaspace size
-XX:MaxMetaspaceSize=512m      # Cap metaspace growth

GC Logging (Java 9+ Unified Logging)

# Enable GC logging
-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=10m

# Detailed GC logging for analysis
-Xlog:gc+heap=debug:file=gc-detail.log

# Legacy (Java 8)
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

Production Recommendations

# Microservice (low-latency, 4GB heap)
java -Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 \
     -Xlog:gc*:file=gc.log:time:filecount=5,filesize=10m \
     -jar service.jar

# High-throughput batch job (16GB heap)
java -Xms16g -Xmx16g -XX:+UseParallelGC -XX:ParallelGCThreads=8 \
     -jar batch-job.jar

# Ultra-low-latency trading system (32GB heap)
java -Xms32g -Xmx32g -XX:+UseZGC \
     -Xlog:gc*:file=gc.log:time:filecount=5,filesize=10m \
     -jar trading-engine.jar

Reading GC Logs

Sample G1 GC Log Entry

[2024-01-15T10:30:45.123+0000][info][gc] GC(42) Pause Young (Normal)
    (G1 Evacuation Pause) 1024M->256M(4096M) 12.345ms

Breakdown:

Warning Signs in GC Logs

Analysis Tools

• GCViewer — open-source desktop tool for visualizing GC logs
• GCEasy (gceasy.io) — web-based GC log analyzer with recommendations
• JVisualVM — real-time monitoring with GC plugin
• Eclipse MAT — memory analyzer for heap dumps
• jstat — command-line GC statistics: jstat -gcutil <pid> 1000

Common Memory Issues and Troubleshooting

1. Memory Leaks

Objects that are still referenced but never used again — GC cannot collect them.

// Classic leak: static collection that grows forever
public class LeakyCache {
    private static final Map<String, Object> cache = new HashMap<>();

    public void addToCache(String key, Object value) {
        cache.put(key, value);  // Never removed — grows until OOM
    }
}

// Fix: Use WeakHashMap, bounded cache, or explicit eviction
private static final Map<String, Object> cache =
    Collections.synchronizedMap(new LinkedHashMap<>(1000, 0.75f, true) {
        protected boolean removeEldestEntry(Map.Entry eldest) {
            return size() > 1000;
        }
    });

Common leak sources:

• Unclosed resources (connections, streams, cursors)
• Static collections without eviction
• Listeners/callbacks never deregistered
• ThreadLocal variables not removed
• ClassLoader leaks (common in app servers)

2. OutOfMemoryError Variants

3. Long GC Pauses — Production Troubleshooting

Scenario: "Your service's P99 latency spikes to 5 seconds every few minutes. What do you do?"

Step-by-step approach:

1. Confirm it's GC: Check GC logs for pauses correlating with latency spikes
2. Identify GC type: Minor GC pauses (usually OK) vs Full GC (problematic)
3. Check heap usage pattern: jstat -gcutil <pid> 1000
4. Analyze: Feed logs into GCEasy or GCViewer
5. Common fixes:
   • If Full GC is frequent: likely memory leak or undersized heap
   • If Minor GC is long: too much surviving data, increase Young Gen
   • If promotion failure: Old Gen cannot accommodate promoted objects
   • Switch to G1 with pause time target, or ZGC for sub-ms pauses

# Quick diagnosis commands
jstat -gcutil <pid> 1000      # GC stats every second
jmap -histo:live <pid>         # Object histogram (triggers Full GC!)
jmap -dump:live,format=b,file=heap.hprof <pid>  # Heap dump for analysis
jcmd <pid> GC.heap_info       # Heap region info (no GC triggered)

Interview Questions