Go vs. Java: Garbage Collection Pauses, Latency Spikes (p99), and Tuning for Concurrent Microservices

Understanding Garbage Collection in Go and Java for Low-Latency Microservices

When building high-throughput, low-latency microservices, the performance characteristics of the underlying runtime’s garbage collector (GC) become a critical factor. Specifically, the frequency and duration of GC pauses can directly impact tail latencies, often measured by p99 or p99.9 percentiles. This post dives into the GC mechanisms of Go and Java, comparing their approaches and providing actionable tuning strategies for minimizing latency spikes.

Go’s Concurrent Garbage Collector: A Generational Leap

Go’s garbage collector has evolved significantly, aiming for minimal stop-the-world (STW) pauses. Modern Go GCs are largely concurrent, meaning the GC work happens alongside the application goroutines. This is achieved through a tri-color mark-and-sweep algorithm with write barriers. The goal is to keep STW pauses in the sub-millisecond range, even for large heaps.

Key characteristics of Go’s GC:

• Concurrent Mark Phase: The GC marks live objects concurrently with the application.
• Write Barriers: These are crucial for maintaining correctness during concurrent marking. They intercept pointer writes from the application and inform the GC about changes to the object graph. Go uses Dijkstra-style write barriers.
• Pacing: The GC dynamically adjusts its pace based on the rate of memory allocation by the application. It tries to stay ahead of allocation to prevent the heap from growing too large and triggering longer STW phases.
• No Generational Collection (historically): Early Go GCs were not generational. While modern Go GCs have some generational-like optimizations, they don’t strictly adhere to the classic generational hypothesis (most objects die young) in the same way as Java’s GC.

Tuning Go GC for Latency

While Go’s GC is designed to be largely automatic, certain environment variables and runtime configurations can influence its behavior, especially under heavy load.

The primary tuning knob is the GOGC environment variable. It controls the heap growth ratio. GOGC=100 means the GC will start when the heap is twice the size of the live data. Increasing GOGC (e.g., to 200 or 300) delays GC cycles, potentially reducing GC frequency but increasing heap usage and the potential for longer STW pauses if they do occur. Decreasing GOGC (e.g., to 50) triggers GC more frequently, keeping heap usage lower but potentially increasing GC overhead.

For latency-sensitive applications, a common strategy is to not aggressively lower GOGC. Instead, focus on efficient memory allocation patterns in the application code. However, if profiling reveals GC is a bottleneck, experimentation with GOGC is warranted. A value around 100-150 is often a good starting point for microservices.

Monitoring GC pause times is paramount. The runtime/debug package provides tools:

import (
	"fmt"
	"runtime/debug"
	"time"
)

func main() {
	// ... application logic ...

	// Trigger a GC and measure pause time
	var m debug.GCStats
	if debug.ReadGCStats(&m) == nil {
		fmt.Printf("Before GC: HeapAlloc = %d, NumGC = %d\n", m.HeapAlloc, m.NumGC)
	}

	start := time.Now()
	debug.FreeOSMemory() // This forces a GC cycle
	duration := time.Since(start)

	if debug.ReadGCStats(&m) == nil {
		fmt.Printf("After GC: HeapAlloc = %d, NumGC = %d, Pause Duration = %v\n", m.HeapAlloc, m.NumGC, duration)
	}
}

More advanced monitoring can be achieved using the GODEBUG environment variable, specifically GODEBUG=gctrace=1. This prints detailed GC statistics to stderr on each GC cycle, including pause times.

GODEBUG=gctrace=1 go run main.go

Example output:

gc 1 @0.123s 1000+1000ms 100% 0+0+0 calls 2000+2000ms 2000ms avg: 2000ms: 100% 0+0+0

The key metrics here are the pause times (e.g., 2000ms). For microservices, you want these to be consistently low, ideally under 1ms for p99. If you see pauses in the tens or hundreds of milliseconds, it’s a strong indicator of GC pressure.

Java’s Garbage Collectors: A Spectrum of Options

Java’s JVM offers a variety of GC algorithms, each with different trade-offs between throughput, latency, and memory footprint. The choice of GC is a critical tuning parameter for Java-based microservices.

Common Java GCs and their latency characteristics:

• Serial GC: Single-threaded, stops the world for collection. Not suitable for low-latency applications.
• Parallel GC (Throughput Collector): Multi-threaded, optimized for throughput. Still has significant STW pauses.
• CMS (Concurrent Mark Sweep): Aims for low pauses by doing most work concurrently. However, it can suffer from fragmentation and has a “concurrent mode failure” where it falls back to a full STW pause if it can’t keep up. Deprecated in Java 9 and removed in Java 14.
• G1 (Garbage-First): The default GC since Java 9. It divides the heap into regions and aims to collect regions with the most garbage first. It offers tunable pause time goals.
• ZGC: A scalable, low-latency GC designed for very large heaps (multi-terabyte) with pause times typically under 10ms, often sub-millisecond. It’s fully concurrent.
• Shenandoah: Another low-pause-time GC, also concurrent, aiming for consistent sub-millisecond pauses regardless of heap size.

Tuning Java GC for Latency (G1, ZGC, Shenandoah)

For modern, latency-sensitive Java microservices, G1 is often the default and a good starting point. ZGC and Shenandoah are excellent choices if sub-millisecond or consistently low millisecond pauses are strictly required, especially with large heaps.

Tuning G1 GC:

The primary tuning parameter for G1 is -XX:MaxGCPauseMillis=N. This sets a target pause time goal. The GC will try to meet this goal by adjusting its collection cycles. Setting this too low can lead to increased GC CPU overhead as the GC works harder to meet an aggressive target.

Other important G1 flags:

• -XX:G1HeapRegionSize=N: Controls the size of G1’s regions. Defaults to a power of 2 between 1MB and 32MB.
• -XX:InitiatingHeapOccupancyPercent=N: The percentage of the heap occupancy at which the concurrent marking cycle is initiated. Defaults to 45. Lowering this can start GC earlier, potentially preventing long pauses but increasing GC frequency.
• -XX:+UseStringDeduplication: Can reduce memory footprint by deduplicating identical strings.

Example JVM arguments for G1:

-XX:+UseG1GC
-XX:MaxGCPauseMillis=50
-XX:G1HeapRegionSize=16m
-XX:InitiatingHeapOccupancyPercent=35
-XX:+ParallelRefProcEnabled
-XX:+DisableExplicitGC
-XX:+UseStringDeduplication

Tuning ZGC and Shenandoah:

These GCs are designed for low latency out-of-the-box. Tuning is often less critical than with G1, but heap sizing and region sizing (for ZGC) can still play a role. They aim for sub-millisecond pauses by performing almost all work concurrently, including stack scanning and object copying.

Example JVM arguments for ZGC:

-XX:+UseZGC
-XX:ConcGCThreads=8  # Adjust based on CPU cores
-Xms4g
-Xmx4g

Example JVM arguments for Shenandoah:

-XX:+UseShenandoahGC
-XX:ShenandoahGCThreads=8 # Adjust based on CPU cores
-Xms4g
-Xmx4g

Monitoring Java GC Performance

The JVM provides extensive GC logging capabilities. Enabling detailed GC logging is crucial for understanding pause times and GC behavior.

For Java 8 and earlier (using G1 or CMS):

-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-Xloggc:/var/log/jvm/gc.log

For Java 9+ (unified logging):

-Xlog:gc*:file=/var/log/jvm/gc.log:time,uptime,level,tags:filecount=5,filesize=10m

Tools like GCViewer, GCeasy, or Elastic APM can parse these logs to visualize GC activity, including pause times, heap usage, and GC throughput. For real-time monitoring, JMX metrics exposed by the JVM (e.g., java.lang.GarbageCollector.*) are invaluable. Prometheus JMX Exporter is a common way to expose these metrics for scraping.

Comparing GC Pauses: Go vs. Java

The fundamental difference lies in their design philosophy and maturity. Go’s GC is designed to be a single, highly optimized, concurrent collector that “just works” with minimal tuning for most applications. Its STW pauses are typically in the sub-millisecond range for modern Go versions.

Java, on the other hand, offers a buffet of GC algorithms. For achieving consistently low p99 latencies (sub-millisecond to a few milliseconds), ZGC and Shenandoah are the current champions. G1 is a strong contender for general-purpose low-latency, but its pause time goals are just that – goals, and can be missed under heavy load or with specific object allocation patterns. The ability to tune and select specific GC algorithms in Java provides immense power but also introduces complexity.

Key Takeaways for Microservices:

• Go: Generally excellent out-of-the-box for low latency. Focus on efficient memory allocation in your Go code and monitor gctrace output. Avoid excessive heap growth.
• Java: If sub-millisecond pauses are non-negotiable, consider ZGC or Shenandoah. For typical microservices, G1 with a tuned MaxGCPauseMillis is often sufficient. Thorough GC logging and analysis are essential.
• Heap Sizing: In both runtimes, appropriate heap sizing is crucial. Too small a heap leads to frequent GC; too large can increase pause times (though modern GCs mitigate this significantly).
• Application Profiling: GC is only one piece of the latency puzzle. Always profile your application to identify other bottlenecks (CPU, I/O, network, lock contention) that might be contributing to high p99 latencies. Tools like pprof (Go) and async-profiler (Java) are indispensable.

Ultimately, the choice between Go and Java for latency-critical microservices depends on team expertise, existing ecosystem, and the specific latency requirements. Both can achieve excellent results, but the path to achieving and maintaining those results differs.