Which GC Algorithms Should You Know?

Five are worth knowing, and they differ mainly in how they trade throughput against pause times.

Serial uses a single thread and a single compacting collector. It has the lowest overhead of all of them and the shortest throughput, which makes it the right choice for small heaps and for command-line tools where start-up time matters more than throughput.

Parallel — also called the throughput collector — uses multiple threads for both the young and the old collections. It gives the best throughput of the lot at the cost of longer pauses, and it is the traditional default for batch processing and for large-heap server workloads where you care about total work done rather than tail latency.

G1 divides the heap into regions of equal size rather than into contiguous spaces, and collects the regions with the most garbage first. It aims for a pause-time target you set, and it compacts as it goes. That makes it a good general-purpose default, and it is the collector to reach for when you need predictable pauses on a large heap without going to the very latest collectors.

ZGC and Shenandoah are the low-latency collectors. Both do most of their work concurrently, using coloured pointers and load barriers so that the garbage collector can move objects around without stopping the application threads. ZGC aims for sub-millisecond pauses, and Shenandoah does something similar with a different implementation strategy. They are the right choice when you have a strict latency service and a large heap.

The selection rule of thumb: default to G1 unless you have a specific reason, choose Parallel for pure throughput, and choose a low-latency collector when tail latency is the thing you are measured on.

Three ways, and the third is the one that actually tells you rather than telling you what was requested.

The command line flags select the collector: -XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseG1GC, -XX:+UseZGC and -XX:+UseShenandoahGC. The startup banner of a JDK that prints the VM arguments also shows which one was enabled.

The management API reports the collectors that are actually installed. GarbageCollectorMXBean gives you a list, and the names are informative — you will see names such as G1 Young Generation and G1 Old Generation for G1, or PS Scavenge and PS Old Generation for the parallel collector. Seeing which beans exist tells you which collector the JVM really chose, which matters because the JVM may ignore your flag if the configuration does not suit it.

import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;

public class Main {
    public static void main(String[] args) {
        // The collectors that are actually installed.
        for (GarbageCollectorMXBean bean : ManagementFactory.getGarbageCollectorMXBeans()) {
            System.out.println("collector : " + bean.getName());
            System.out.println("  collections : " + bean.getCollectionCount());
            System.out.println("  time ms     : " + bean.getCollectionTime());
        }

        // The JVM startup banner lists the flags that were in effect.
        System.out.println("java.vm.info   : " + System.getProperty("java.vm.info"));
        System.out.println("see the VM output for the flags in effect");
    }
}

The output lists the collectors with their names, which identifies the algorithm in use, along with the collection counts and cumulative times. The vm info property usually contains the full command line the JVM was started with, including the collector flag.

Two practical points. The collector can be changed at run time with a management operation in some cases, but changing it under load is not something you should do casually. And the most reliable diagnosis of a pause problem is not the collector's identity but its behaviour — enable unified GC logging and look at the pause histogram, which tells you the actual distribution of pause times rather than the average.

All of the modern collectors are generational — they exploit the observation that most objects die young — but they differ in how they lay out the heap and how they handle the old generation.

The generational hypothesis says that most objects become unreachable shortly after allocation, so collecting the young generation frequently is cheap and reclaims most garbage. That is common to every collector here. The difference is in what happens when an object survives.

The Serial and Parallel collectors use a contiguous heap: a young generation split into Eden and survivor spaces, and a contiguous old generation. They promote surviving objects into the old generation by copying them, and a major collection compacts the whole old space.

G1 replaces the fixed spaces with a set of equally sized regions that the collector assigns to roles as needed. It collects the regions with the highest garbage ratio first, which is how it hits a pause-time target on a large heap. It still compacts, but it does so incrementally rather than in one big stop-the-world event.

ZGC and Shenandoah take the concurrent idea much further. They do the marking, relocation and compaction while the application keeps running, using coloured pointers and load barriers to intercept the references that would otherwise become stale when an object moves. The pauses shrink to the point where they are barely measurable, at the cost of some throughput and a little extra CPU for the barriers.

The practical takeaway for an interview: pick a collector based on which of throughput or tail latency you are actually measured on, and do not tune the heap flags before checking which collector is in use.