Serial GC vs Parallel GC vs CMS vs G1.

Garbage collectors are like janitors with very different schedules: one works alone, one brings a crew, one tries to clean quietly in the background, and one rearranges the whole room so the mess is easier to remove.

Question: What is the difference between Serial GC, Parallel GC, CMS, and G1 in Java?

Answer: These are different Java garbage collectors with different goals. Serial GC uses one thread and is simple, Parallel GC uses many threads to maximize throughput, CMS tries to reduce pause times by doing most old-generation work concurrently, and G1 is a region-based collector that aims for predictable pauses while still keeping good throughput. On modern Java, G1 is the default, and CMS is historical because it was removed in JDK 14.

Interview-Ready Answer: I’d explain it this way: Serial GC is the simplest collector and stops the world with one thread, so it’s best for tiny heaps or single-core situations. Parallel GC also stops the world, but uses multiple threads to finish faster, so it’s usually the throughput choice. CMS was designed for lower pause times by doing old-gen marking and sweeping concurrently, but it can fragment the heap and it was removed in JDK 14. G1 is the modern default; it splits the heap into regions, does concurrent marking, and then evacuates selected regions to keep pauses more predictable, with a typical pause target like 200 ms rather than a hard guarantee.

Big picture: what GC is trying to do

Java allocates objects on the heap. Some objects die quickly, like temporary strings, request objects, and loop-local buffers. A garbage collector is the JVM’s memory manager: it finds objects that are no longer reachable and frees their memory. In interviews, the key trade-off is always throughput versus pause time. Throughput means how much useful work the app does overall; pause time means how long the app must stop while GC runs. A stop-the-world pause means application threads are temporarily frozen.

How the four collectors behave under the hood

1. Objects are allocated in the young generation. New objects usually go into Eden, the main nursery area. If they die there, collection is cheap.
2. Serial GC handles the pause with one thread. When Eden fills, the JVM stops application threads and uses a single GC thread to copy live objects out of young space. This is simple, low-overhead, and easy to predict on tiny heaps, but it can be slow on large heaps because only one CPU core is doing the work.
3. Parallel GC does the same kind of stop-the-world work, but with many threads. The collector splits the work across worker threads, often near the number of available CPUs, so the pause ends sooner. The total CPU work is similar, but the wall-clock pause is usually much shorter than Serial GC. This is why Parallel GC is often the batch-job collector.
4. CMS means Concurrent Mark Sweep. Concurrent means it runs alongside the application for most of its work. It starts with a short stop-the-world initial mark, then a concurrent mark phase to discover live old-gen objects, then a short stop-the-world remark to catch changes, and finally a concurrent sweep phase to reclaim dead memory. The big catch is that CMS does not compact the heap, so free space can become fragmented into small holes.
5. G1 means Garbage-First. It divides the heap into many equal-sized regions, usually between 1 MB and 32 MB depending on heap size. It does concurrent marking to learn which regions have the most garbage, then it chooses a collection set of regions to evacuate. Evacuation means copying live objects out of selected regions into fresh ones, which both reclaims memory and compacts it. That is why G1 handles fragmentation much better than CMS.
6. Full GC is the fallback pain point. If the heap is too full, or CMS gets fragmented, or a collector cannot finish its normal cycle in time, the JVM may fall back to a long stop-the-world Full GC. That is the event that kills latency graphs and wakes up on-call engineers.

Quick comparison

When and why to use each

Use Serial GC when the heap is small and simplicity matters more than raw speed. Use Parallel GC when you want maximum throughput and can tolerate longer pauses, such as data processing or offline batch work. CMS used to be chosen for low-pause systems, but it is now mostly an interview topic because it was removed in JDK 14. Use G1 for most modern server applications because it balances latency and throughput better than the older collectors.

Performance and interview details

The work each collector does is roughly proportional to the amount of live data it must scan or move. Parallel GC reduces elapsed pause time by using more CPU threads, but not the total amount of work. G1 adds bookkeeping for regions, remembered sets, and concurrent marking, so it has more overhead than Serial or Parallel, but it buys better pause predictability. A good memory detail: G1’s pause goal is often set with -XX:MaxGCPauseMillis, whose default target is commonly 200 ms, but that is only a goal, not a promise. Another classic G1 detail is that objects larger than half a region are treated as humongous, which can affect fragmentation and compaction behavior.

Version differences you should know

• Since Java 9, G1 has been the default on HotSpot server-class machines.
• CMS was deprecated before being removed in JDK 14, so you should talk about it as a historical collector.
• Parallel GC is still a strong choice when raw throughput matters more than latency.

Memory hook: imagine a house clean-up team: Serial is one cleaner, Parallel is a full crew, CMS is a quiet cleaner who works around people but leaves messy corners, and G1 is a project manager who sorts the house into rooms and cleans the worst rooms first.

Real-World Story: A checkout service at a retail company starts timing out during a holiday sale. The service uses a lot of short-lived request objects, but it also keeps some customer and pricing data alive for longer. On older JVMs, the team tried CMS to keep pauses low. It worked for a while, then traffic grew and the heap became fragmented. The logs started showing phrases like concurrent mode failure and occasional long Full GC pauses. Users saw slow checkouts, retries from the load balancer, and spikes in 504 Gateway Timeout responses. When the team switched to G1, the collector compacted regions during evacuation, pauses became more predictable, and the p99 latency graph flattened out. The important lesson: a collector choice is not just a JVM setting; it changes user-visible behavior under load.

What goes wrong when you misunderstand it: teams sometimes pick a collector because it sounds “fast” instead of matching it to the workload. A throughput collector on an API server can create long pauses, while a low-pause collector on a batch job may waste CPU and reduce total work completed. The symptom is usually not a crash first; it is latency spikes, timeout logs, and only later an emergency heap-size increase.

Follow-up & Tricky Questions:

• Why was CMS removed? CMS had low pauses, but it added complexity and suffered from heap fragmentation because it did not compact memory. Over time, G1 became the better general-purpose option, so CMS was deprecated and then removed in JDK 14.
• Why does G1 have better pause predictability? G1 works on regions and can choose a smaller set of regions to evacuate based on how much garbage they contain. That lets it aim for a pause target instead of scanning a huge contiguous old generation at once.
• What is the difference between throughput and latency? Throughput is how much work the JVM completes per unit time overall, while latency is how long one request waits. Parallel GC optimizes throughput, while G1 and CMS were designed to improve latency.
• When would you still choose Serial GC? For very small heaps, tiny containers, or single-core environments, the overhead of more advanced collectors can outweigh their benefits. Serial is simple and can be perfectly fine there.
• What causes Full GC? A Full GC usually happens when the JVM cannot reclaim enough space with a normal cycle, or when fragmentation or allocation pressure becomes too high. It is the collector event you want to avoid in latency-sensitive services.
• Does G1 guarantee the pause target? No. -XX:MaxGCPauseMillis is a goal used by the collector’s heuristics, not a hard real-time guarantee, so a badly tuned heap or too much live data can still cause longer pauses.
• Is Parallel GC always slower than G1? No. Parallel GC can beat G1 on raw throughput if the application is batch-like and pause time does not matter much. The best collector depends on the workload, not on a ranking table.
• Is CMS still available on current Java? No. That is the classic gotcha: CMS is historical and not present in modern JDKs starting with 14.
• Does G1 eliminate fragmentation entirely? It greatly reduces it because it evacuates live objects and compacts regions, but bad heap pressure and large humongous objects can still make behavior less ideal.

Common Mistakes:

• Mistake: Saying CMS is the modern default. Correction: G1 is the modern default on HotSpot server-class machines since Java 9.
• Mistake: Thinking CMS compacts memory. Correction: CMS marks and sweeps, but it does not compact, which is why fragmentation is its classic weakness.
• Mistake: Treating G1’s pause target as a promise. Correction: It is a tuning goal, not a guarantee; high live data can still produce longer pauses.
• Mistake: Mixing up throughput and latency. Correction: Parallel GC is usually about throughput; G1 is usually about balanced latency plus throughput.

Memory Hook: One cleaner, many cleaners, quiet cleaner, smart room planner = Serial, Parallel, CMS, G1.

Cheat Sheet:

• Serial GC = one thread, stop-the-world, tiny heaps.
• Parallel GC = many threads, stop-the-world, best throughput.
• CMS = concurrent old-gen cleanup, low pauses, no compaction, removed in JDK 14.
• G1 = region-based, concurrent marking, evacuation, predictable pauses, default since Java 9.
• Choose by workload: tiny/single-core, batch, legacy low-pause, or modern general-purpose server.

Practice Tasks:

• Run the provided program with the default JVM, then with -XX:+UseSerialGC and -XX:+UseParallelGC, and compare the printed GC counts.
• Start the program with a small heap such as -Xmx64m and the stress argument to see how long-lived objects can create pressure.
• Read the JVM flag output for your version and identify which collector is the default on your machine.