Unlocking Java Memory: How Garbage Collection Works and Why It Matters

Overview

Memory reclamation is like cleaning a house; the user is the system, and the process is similar to ordinary systems. The main requirements are correctness and efficiency without causing significant impact on user threads.

Design Questions

Which objects need to be reclaimed? Objects must be identified as unreachable. Two main marking algorithms exist:

Reference counting – increments on reference acquisition and decrements on release, but cannot resolve cyclic references and is not used by Java.

Root tracing – starts from GC roots and marks all reachable objects; unreachable objects are reclaimed. Java’s JVM uses this approach.

Who performs the reclamation? The garbage collector runs in a dedicated thread within the JVM, deciding when and how to collect.

Where does reclamation occur? Primarily on the heap; stack reclamation is difficult and rarely performed.

When does reclamation happen? Generally when memory is low. Different collectors have different trigger strategies. The basic idea is stop‑the‑world collection, though modern collectors like CMS and G1 allow concurrent collection.

How is reclamation performed? Three fundamental algorithms are used:

Mark‑Sweep – marks live objects then sweeps away dead ones, which can cause fragmentation.

Mark‑Copy – copies live objects to a new space, eliminating fragmentation but requiring double the memory.

Mark‑Compact – marks live objects and compacts them to one end of the heap, then clears the remaining space.

Collector Implementations in HotSpot

The heap is divided into generations: Young and Old. Young generation objects are short‑lived and are collected using the copy algorithm. Old generation objects live longer and are collected using mark‑sweep and mark‑compact algorithms.

Collector families include:

Young generation: Serial (single‑threaded), ParNew (multithreaded), Parallel Scavenge (high CPU throughput).

Old generation: Serial Old (single‑threaded), Parallel Old (multithreaded, high throughput).

CMS (Concurrent Mark‑Sweep) Collector

CMS allows most of the collection work to run concurrently with user threads, reducing pause times. Its phases are initial marking, concurrent marking, remark, and concurrent sweeping. If concurrent sweeping cannot keep up, a Concurrent Mode Failure may trigger a single‑threaded Full GC.

G1 (Garbage‑First) Collector

Introduced in JDK 7, G1 replaces CMS’s mark‑sweep with a mark‑compact approach, dividing the heap into many regions and prioritizing those with the most garbage. It aims to provide low‑pause, real‑time garbage collection for large heaps.

Conclusion

No single garbage collector solves every problem; the choice depends on the application scenario. Single‑threaded Serial and Serial Old collectors are still optimal on single‑CPU systems, while newer collectors like G1 target high‑throughput, low‑latency needs.

References

"深入理解 Java 虚拟机" (Deep Understanding of the Java Virtual Machine)

Oracle Labs – Garbage Collection: http://labs.oracle.com/jtech/pubs/#gc