Java Garbage Collection: Types and Tuning

Garbage collection is one of the core features that makes Java such a developer-friendly language. It relieves me from the tedious and error-prone task of manual memory management, letting me focus more on writing business logic. Yet, despite its convenience, garbage collection (GC) remains a complex topic. A deep understanding of how it works, the different types of garbage collectors available, and how to tune them can drastically improve application performance and resource utilization.

In this article, I will walk you through the basics of Java garbage collection, explore the different types of garbage collectors, and share insights on tuning them effectively based on my experience managing Java applications in production.

What Is Garbage Collection?

In Java, when objects are no longer referenced, they become eligible for garbage collection the process of automatically reclaiming memory occupied by objects that are no longer needed. This process prevents memory leaks and helps maintain the health of long-running applications.

The Java Virtual Machine manages this process transparently, but it uses sophisticated algorithms and heuristics under the hood to decide when and how to free memory efficiently.

How Garbage Collection Works: An Overview

At a high level, the JVM allocates memory on the heap for new objects. Over time, as objects become unreachable, the garbage collector identifies and frees the memory. The key challenge lies in doing this without causing long pauses that impact application responsiveness.

To achieve this, JVM divides the heap into different regions and applies various algorithms tailored for those regions.

Generational Garbage Collection

The most commonly used garbage collection approach in Java is generational GC, based on the observation known as the weak generational hypothesis: most objects die young.

The heap is divided into three main regions:

• Young Generation: Newly created objects are allocated here. It’s subdivided into Eden space and two Survivor spaces.
• Old (Tenured) Generation: Objects that survive several GC cycles in the young generation get promoted here.
• Permanent Generation (or Metaspace in newer JVMs): Stores class metadata, method data, and related info.

Garbage collection occurs more frequently in the young generation because most objects there become unreachable quickly. The old generation is collected less often but involves more work due to the volume and lifespan of objects.

Types of Garbage Collectors

The JVM offers multiple garbage collectors, each optimized for different scenarios. Choosing and tuning the right one depends on your application’s behavior, latency requirements, and hardware environment.

Serial Garbage Collector

The Serial GC uses a single thread to perform all garbage collection work. It stops all application threads during GC, making it suitable only for small applications or environments with limited CPU resources.

In my early projects or simple utilities, Serial GC’s simplicity was enough and offered predictable pauses, but it doesn’t scale well for larger or multi-threaded applications.

You enable it using:

bash -XX:+UseSerialGC

Parallel Garbage Collector (Throughput Collector)

The Parallel GC uses multiple threads to perform garbage collection in the young generation, improving throughput. It still pauses application threads during GC but leverages CPU parallelism to shorten pause durations.

This collector is a good default for CPU-rich environments where throughput is more critical than low latency.

You can enable it with:

bash -XX:+UseParallelGC

CMS (Concurrent Mark-Sweep) Collector

CMS aims to reduce pause times by performing most of its work concurrently with the application threads. It targets applications requiring low latency and responsiveness.

CMS divides the old generation collection into phases: initial mark, concurrent mark, remark, and concurrent sweep. Although it reduces pause times, it can cause fragmentation and higher CPU usage.

To enable CMS:

bash -XX:+UseConcMarkSweepGC

CMS has been deprecated in recent Java versions in favor of more advanced collectors.

G1 (Garbage-First) Collector

The G1 collector is designed for large heaps and multiprocessor machines, providing a balance between throughput and low pause times.

G1 divides the heap into many equally sized regions and prioritizes collecting regions with the most garbage first. It performs both concurrent and parallel phases to minimize pauses.

I switched to G1 in several large-scale projects and noticed significant improvements in pause predictability and overall performance.

Enable G1 with:

bash -XX:+UseG1GC

Z Garbage Collector (ZGC)

ZGC is a scalable low-latency collector introduced in recent Java versions. It can handle heaps ranging from a few gigabytes to multi-terabytes with pause times typically under 10 milliseconds.

ZGC performs most of its work concurrently, using colored pointers and load barriers to track object references efficiently.

To enable ZGC (available in Java 11+):

bash -XX:+UseZGC

Shenandoah

Shenandoah is another low-pause-time collector developed by Red Hat, similar to ZGC in design and goals. It performs concurrent compaction to reduce fragmentation.

Enable Shenandoah in supported JVMs with:

bash -XX:+UseShenandoahGC

Tuning Garbage Collection

Tuning garbage collection involves adjusting JVM options to optimize pause times, throughput, and memory usage based on your application’s needs.

Heap Size and Generation Sizes

The size of the heap and its generations strongly impacts GC behavior.

• Initial heap size (-Xms) and maximum heap size (-Xmx): Setting these appropriately avoids frequent heap resizing and OutOfMemoryErrors.
• Young generation size (-Xmn or tuning with G1 options): A larger young generation can reduce promotions to the old generation but may increase pause times.
• Survivor spaces: Balancing survivor spaces affects the promotion threshold and object copying efficiency.

I learned that monitoring heap usage with tools like VisualVM or Java Mission Control helps set these parameters more effectively.

Garbage Collection Logs and Monitoring

To tune GC, you need visibility into its behavior. Enabling detailed GC logging reveals pause durations, frequency, and memory usage patterns.

For Java 8 and below:

bash -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

For Java 9 and above (using unified logging):

bash -Xlog:gc*,safepoint:/path/to/gc.log:time,uptime,level,tags

Analyzing logs helps identify excessive pauses, frequent full GCs, or memory leaks.

Pause Time Goals

Some applications require strict latency guarantees, such as interactive systems or real-time applications. Setting pause time goals with collectors like G1 or ZGC lets the JVM adjust its work to meet these targets.

For example, with G1:

bash -XX:MaxGCPauseMillis=200

This attempts to keep pauses below 200 milliseconds.

Tuning Specific Collectors

• Parallel GC: Adjust the number of GC threads with -XX:ParallelGCThreads.
• CMS: Tune initial mark and remark threads, and set up concurrent mode failure thresholds.
• G1: Control heap region sizes, initiate concurrent cycles sooner, or adjust heap occupancy thresholds.
• ZGC and Shenandoah: Mostly self-tuning but allow some flags for diagnostics or special cases.

Common Garbage Collection Problems and How I Fix Them

Long Pause Times

Excessive pause times disrupt application responsiveness. Usually, these are caused by:

• Full GCs triggered by memory exhaustion.
• Large young generation collections.
• Fragmented old generation.

Addressing these involves tuning heap sizes, switching collectors, or improving application memory usage.

Frequent Full GCs

Full GCs are costly and often signal memory leaks or insufficient heap size.

Using profiling tools, I track down references preventing object reclamation, fix leaks, or increase heap size.

Memory Leaks

Even with GC, memory leaks happen if objects are unintentionally retained. Tools like Eclipse MAT help analyze heap dumps to find leak suspects.

CPU Overhead

High GC CPU usage reduces resources available for the application. Adjusting GC threads and choosing appropriate collectors helps balance CPU use.

Best Practices for Garbage Collection

• Start with reasonable defaults and profile your application.
• Use the newest stable JVM and collectors, benefiting from improvements.
• Enable detailed GC logging and monitor regularly.
• Tune heap sizes based on actual usage patterns.
• Consider application-specific requirements: throughput vs latency.
• Regularly analyze heap dumps to catch leaks early.
• Avoid premature optimization; focus on real bottlenecks.

Tools That Help Me Manage GC

Over the years, I’ve found several tools invaluable:

• VisualVM: For live monitoring and heap analysis.
• Java Mission Control: For advanced profiling and flight recording.
• Eclipse Memory Analyzer: For deep heap dump analysis.
• GCViewer and GCeasy: For visualizing and analyzing GC logs.

These tools offer insights that make tuning much more effective and less guesswork.

Final Thoughts

Garbage collection is both a blessing and a challenge in Java. While it frees me from manual memory management, it requires careful tuning and understanding to avoid performance pitfalls.

Different garbage collectors suit different needs, and no one-size-fits-all solution exists. The key lies in observing your application’s behavior, choosing an appropriate collector, and tuning it to balance throughput and pause times.

By investing time to understand Java garbage collection deeply, I’ve gained the ability to build more performant, stable, and scalable applications. I encourage you to dive into GC logs, experiment with collectors, and use the rich set of JVM options and tools to tailor garbage collection to your specific use cases.