Serial vs Parallel GC: Throughput-Focused Garbage Collectors

Serial and Parallel are the oldest garbage collectors in the JVM. They share a philosophy: maximize how much work the application does versus how much time GC steals. They are not flashy. No sub-millisecond pauses here. What they deliver is raw throughput - the highest percentage of CPU time possible going to your application instead of the garbage collector.

This covers how each works, when to use one versus the other, and the tuning flags that actually matter.

Introduction

Serial and Parallel are the workhorse garbage collectors in the JVM — the oldest collectors, with the simplest design, and the ones that deliver the highest raw throughput when configured correctly. They share a philosophy: maximize the percentage of CPU time that goes to your application rather than to GC. They are not flashy; there are no sub-millisecond pauses here. What they deliver is efficiency — the most application work per unit of wall-clock time on a given hardware configuration.

The key difference between them is that Serial uses a single GC thread while Parallel uses multiple threads to perform concurrent mark, sweep, and compaction. This makes Parallel significantly faster on multi-core systems for throughput-bound workloads. Understanding when to reach for one versus the other — or when to skip both in favor of a low-pause collector like G1, ZGC, or Shenandoah — requires knowing the trade-off between throughput, latency, and footprint. This post walks through how each collector works internally, the JVM flags that control them, and the concrete scenarios where each is the right choice.

When to Use This Knowledge

Use when:

• Building batch processing, ETL, or data pipeline applications where throughput matters most
• Running on single-core or resource-constrained environments
• Debugging why your application is not utilizing CPU fully during GC
• Choosing a GC strategy before reaching for the low-latency collectors (G1, ZGC, Shenandoah)

Do not use when:

• Your application requires low pause times (sub-second GC pauses are unacceptable)
• You are running on machines with many cores under reactive workloads
• You have strict latency SLAs that GC pauses would violate

When NOT to Use This Knowledge

If your batch pipeline runs with multi-second pauses and CPU utilization is within budget, tuning ParallelGCThreads or SurvivorRatio is effort wasted. The default JVM ergonomics handle these scenarios fine without intervention.

The trap is thinking you need to master GC algorithms before you have a GC problem. Profilers and monitoring should guide your tuning. If your GC logs show healthy collection frequencies and pause times within your SLA thresholds, leave the defaults alone. Premature tuning based on benchmarks rather than production metrics leads to brittle configurations that are hard to maintain.

For applications needing sub-200ms response times under load, Serial and Parallel GC are the wrong tool. Evaluate G1, ZGC, or Shenandoah instead. Spending time on Parallel GC internals for a low-latency use case is a dead end. For continued learning, explore the Advanced Java & JVM Internals roadmap.

The Throughput Goal

Throughput-focused collectors optimize for this equation:

Throughput = Application Time / (Application Time + GC Time)

If your application runs for 1000ms and spends 50ms in GC, your throughput is 1000 / 1050 = 95.2%. Serial and Parallel collectors push this number as high as possible. They do not care about individual pause times as long as the overall ratio looks good.

Serial GC

Serial GC uses a single thread for all garbage collection work. It stops the application world (Stop-The-World) while it runs.

graph TB
    subgraph SerialGC["Serial GC - Single Thread"]
        direction TB
        APP["Application Thread PAUSED"] --> STW1["Mark Phase<br/>(single thread)"]
        STW1 --> STW2["Sweep/Compact<br/>(single thread)"]
        STW2 --> RESUME["Resume Application"]
    end

How It Works

• Young generation uses a stop-the-world copying collector (similar to the basic Copying algorithm)
• Old generation uses a stop-the-world Mark-Compact collector
• Everything runs on a single thread
• The world stops while GC runs

When to Use Serial GC

Serial GC is viable in specific scenarios:

1. Very small heaps (under 100MB) - no benefit to parallelism overhead
2. Single-core machines - multiple threads would compete for CPU anyway
3. Batch jobs where pauses do not matter - ETL pipelines, nightly batch processing
4. Resource-constrained containers - avoids thread creation overhead

JVM Flags for Serial GC

-XX:+UseSerialGC
-Xms512m -Xmx512m    # Small, stable heap

Key Characteristics

Aspect	Behavior
GC threads	1
Young gen collector	Copying (stop-the-world)
Old gen collector	Mark-Compact (stop-the-world)
Throughput	Moderate - limited by single thread
Memory footprint	Lowest
CPU overhead	Minimal
Pause times	Longest per collection

Parallel GC

Parallel GC (also called Throughput GC or Parallel Old GC) uses multiple threads for GC work. It is the default collector on most JVM installations for server workloads.

graph TB
    subgraph ParallelGC["Parallel GC - Multiple Threads"]
        direction TB
        APP["Application Threads PAUSED"] --> PT["Parallel Mark Phase<br/>(N threads)"]
        PT --> ST["Parallel Sweep/Compact<br/>(N threads)"]
        ST --> RESUME["Resume Application"]
    end

How It Works

• Young generation uses a multi-threaded stop-the-world copying collector
• Old generation uses a multi-threaded stop-the-world Mark-Compact collector
• Number of GC threads controlled by -XX:ParallelGCThreads=N
• Default thread count: max(Runtime.availableProcessors() - 1, 8) for large machines
• The world stops while GC runs on multiple threads

When to Use Parallel GC

Parallel GC shines when:

1. CPU is abundant - many cores available for GC work
2. Throughput is the primary metric - batch processing, computation-heavy workloads
3. Pause times in the seconds range are acceptable - most pauses are under 1 second but can be longer
4. Memory is plentiful - parallel GC benefits from larger heaps where work can be divided

JVM Flags for Parallel GC

-XX:+UseParallelGC          # Parallel Young Gen
-XX:+UseParallelOldGC      # Parallel Old Gen (usually enabled with UseParallelGC)
-Xms4g -Xmx4g              # Heap sized for your workload
-XX:ParallelGCThreads=16   # Explicit thread count (optional)
-XX:+UseAdaptiveSizePolicy  # Enable adaptive heap sizing (default ON)

Key Characteristics

Aspect	Behavior
GC threads	Multiple (CPU-dependent)
Young gen collector	Parallel Copying (stop-the-world)
Old gen collector	Parallel Mark-Compact (stop-the-world)
Throughput	Highest of all collectors
Memory footprint	Standard
CPU overhead	Higher than Serial
Pause times	Shorter than Serial per unit of work, but still Stop-The-World

Comparing Serial and Parallel

Aspect	Serial GC	Parallel GC
Threads	1	Many
Throughput	Lower	Highest
Pause time per GC	Longer	Shorter per unit of work
CPU overhead	Minimal	Higher
Memory overhead	Minimal	Slight (thread stacks)
Best for	Small heaps, single core	Large heaps, multi-core batch
Default for	Client-mode JVMs	Server-mode JVMs

Production Failure Scenarios

1. Full GC Freezes in Parallel GC

Symptom: Application freezes for several seconds during old generation collection. GC logs show Full GC with long pause times.

Cause: Even with multiple threads, a full heap Mark-Compact is expensive. With many live objects, compaction can take seconds.

Solution: Reduce heap size to reduce work per GC cycle. Or switch to G1/ZGC for shorter pauses. Profile to confirm this is the actual GC cause.

# Example GC log showing long Full GC
[Full GC (Allocation Failure) [PSYoungGen: 512K->0K(1536K)] [ParOldGen: 4095M->4095M(4096M)] 4.1234567secs]

2. Excessive GC Thread Contention

Symptom: High CPU usage during GC but low overall throughput. GC threads fighting for CPU on a loaded system.

Cause: Too many GC threads (-XX:ParallelGCThreads) on a system with limited cores, or GC threads competing with application threads.

Solution:

# Limit GC threads to avoid contention
-XX:ParallelGCThreads=8

# Or use fewer threads than available cores
# Rule of thumb: leave 1-2 cores for application threads

3. Adaptive Size Policy Misfire

Symptom: Heap resizing causes performance instability - throughput spikes and dips unpredictably.

Cause: -XX:+UseAdaptiveSizePolicy automatically adjusts heap sizes based on allocation behavior, which can cause resizing during critical production periods.

Solution:

# Disable adaptive sizing
-XX:-UseAdaptiveSizePolicy

# Or set explicit ratios
-XX:NewRatio=2
-XX:SurvivorRatio=8

Implementation Snippets

Enabling and Configuring Parallel GC

# Basic Parallel GC configuration
java -XX:+UseParallelGC \
     -XX:+UseParallelOldGC \
     -Xms4g -Xmx4g \
     -XX:ParallelGCThreads=16 \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps \
     -Xlog:gc*:file=gc.log \
     -jar myapp.jar

Reading Parallel GC Logs

Parallel GC logs show which phases are running and how long each takes:

[Full GC [PSYoungGen: 512K->0K(1536K)] [ParOldGen: 4095M->4095M(4096M)] 4.1234567secs]
[Times: user=32.10 sys=1.20, real=4.12 secs]

• user = CPU time across all threads (32 seconds of CPU work done in 4 seconds wall time = 8 threads)
• sys = time spent in kernel calls
• real = actual wall clock time (should be close to user/N for N threads)

Checking Active GC Algorithm

import java.lang.management.*;
import java.util.*;

public class WhichGC {
    public static void main(String[] args) {
        List<GarbageCollectorMXBean> gcs = ManagementFactory.getGarbageCollectorMXBeans();
        for (GarbageCollectorMXBean gc : gcs) {
            System.out.println("Collector: " + gc.getName());
            System.out.println("  Pools: " + Arrays.toString(gc.getMemoryPoolNames()));
        }

        // Check if adaptive sizing is on
        RuntimeMXBean runtime = ManagementFactory.getRuntimeMXBean();
        System.out.println("Input args: " + runtime.getInputArgs());
    }
}

Observability Checklist

• Enable GC logging: -Xlog:gc*:file=gc.log
• Parse GC logs for pause time distribution: look for real= vs user= to spot contention
• Monitor jstat -gc <pid> for FC (Full GC count) and FGCT (Full GC time)
• Track heap occupancy before and after Full GC to understand live set size
• Watch CPU usage during GC events - high sys time may indicate OS-level overhead
• Use -XX:PrintGCApplicationConcurrentTime to measure time between GC pauses
• Consider NMT (Native Memory Tracking): -XX:NativeMemoryTracking=summary

Security Notes

1. GC Logs can reveal application allocation patterns and memory behavior - protect them
2. JMX/Management Interface access to GC beans should be restricted in production
3. Heap Dumps after OOM contain full application state - handle with care
4. NMT output can reveal native memory allocation details useful for attacks

Common Pitfalls / Anti-Patterns

Pitfall	What happens	Fix
Too many GC threads	GC threads fight application threads for CPU	Set -XX:ParallelGCThreads explicitly
AdaptiveSizePolicy on in production	Unpredictable heap resizing	Disable with -XX:-UseAdaptiveSizePolicy
Setting heap too large	Fewer but longer Full GCs	Tune based on live set size
Setting heap too small	Constant GC thrashing	Profile to find working set size
Ignoring old gen occupancy	Promotion failure causes Full GC	Monitor promotion rate with jstat

Quick Recap Checklist

• Serial GC = single thread, lowest throughput, lowest overhead
• Parallel GC = multiple threads, highest throughput, default for server workloads
• Throughput = Application Time / (Application Time + GC Time)
• Parallelism helps when CPU cores are plentiful and work is divisible
• Both are Stop-The-World collectors - pauses freeze the entire application
• -XX:ParallelGCThreads controls thread count - tune based on available cores
• -XX:+UseAdaptiveSizePolicy auto-tunes heap sizes but can cause instability
• For low-latency requirements, look at G1, ZGC, or Shenandoah

Interview Questions

Further Reading

• Java Platform, Standard Edition Deployment Guide - Ergonomics - How JVM ergonomics auto-tune GC for server-class machines
• Parallel GC Internals - Azul Systems Blog - Deep dive into parallel collection threading
• Java HotSpot VM Options for GC - Complete reference for GC-related JVM flags
• JVM Performance Tuning with jstat - Practical guide to using jstat for GC diagnostics

Conclusion

Serial GC uses one thread for all GC work; Parallel GC uses multiple threads for higher throughput. Both are stop-the-world collectors that freeze the application during collections. Parallel GC is the default for server workloads on multi-core machines and maximizes throughput at the cost of longer individual pauses. Serial GC suits small heaps and single-core environments. For low-latency needs, look to G1, ZGC, or Shenandoah instead.