Java Performance: JVM Tuning, GC Algorithms, and Memory Management

Java performance optimization requires understanding the JVM memory model, garbage collection mechanics, and tuning parameters. This guide covers the essential concepts and practical configurations for production systems.

JVM Memory Architecture

The JVM divides memory into several distinct regions, each serving specific purposes.

Heap Memory

The heap stores all objects and is divided into generations for GC efficiency:

• Young Generation: New objects allocated here. Contains Eden and two Survivor spaces (S0, S1).
• Old Generation: Long-lived objects promoted from Young Gen after surviving multiple GC cycles.
• Metaspace: Stores class metadata (Java 8+). Grows natively, not part of heap.

Non-Heap Memory

• Stack: Per-thread memory for local variables and method calls
• Code Cache: JIT-compiled native code
• Direct Buffers: Off-heap memory allocated via ByteBuffer.allocateDirect()
• Native Memory: Internal JVM structures, class metadata, code cache, and thread stacks

Garbage Collection Algorithms

Serial GC

Single-threaded collector suitable for small applications and single-core machines.

-XX:+UseSerialGC

Use case: Small heaps (< 2GB), applications with < 2 CPUs, client applications, simple microservices.

Parallel GC (Throughput Collector)

Multi-threaded collector maximizing throughput by parallelizing GC work.

-XX:+UseParallelGC
-XX:ParallelGCThreads=4

Use case: Batch processing, reporting systems where pause times matter less than throughput.

G1 GC (Garbage First)

Region-based collector designed for predictable pause times with large heaps. Default GC since JDK 9.

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=16m

Use case: General-purpose server applications, heaps 4GB+, mixed workloads.

ZGC (Z Garbage Collector)

Low-latency collector with pause times under 10ms, even for terabyte heaps. Production-ready since JDK 15, generational ZGC available in JDK 21+.

-XX:+UseZGC
-XX:ZCollectionInterval=5  # Forces GC at fixed 5-second intervals regardless of memory pressure

Use case: Low-latency applications, real-time systems, large heaps (16GB+).

Shenandoah

Another low-pause collector using concurrent compaction.

-XX:+UseShenandoahGC
-XX:ShenandoahGCHeuristics=compact

Use case: Similar to ZGC, good for applications requiring consistent response times.

JVM Tuning Parameters

Memory Sizing

-Xms4g                          # Initial heap size
-Xmx4g                          # Maximum heap size
-Xmn1g                          # Young generation size (discouraged with G1/ZGC - interferes with adaptive sizing)
-XX:MetaspaceSize=256m          # Initial metaspace
-XX:MaxMetaspaceSize=512m       # Max metaspace

Best practice: Set -Xms and -Xmx to the same value to prevent runtime resizing overhead. Avoid fixed -Xmn with adaptive collectors (G1/ZGC).

Container Support

-XX:+UseContainerSupport        # Enabled by default since JDK 10+
-XX:MaxRAMPercentage=50.0       # Use 50% of container memory (JDK 10+)

GC Logging and Diagnostics

# Java 11+
-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=10m

# Java 8
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

# Native Memory Tracking
-XX:NativeMemoryTracking=summary  # or 'detail' for comprehensive analysis

Thread and JIT Tuning

-XX:CICompilerCount=4           # JIT compiler threads
-XX:+UseStringDeduplication     # String deduplication (G1/ZGC)
-XX:+UseCompressedOops          # Compressed object pointers (default for heaps where 8-byte alignment allows)
-XX:+UseCompressedClassPointers # Compressed class pointers

Note: Compressed OOPs work when object alignment allows 8-byte addressing with 3-bit shift, typically up to ~32GB heap.

Memory Management Best Practices

Object Allocation Patterns

Avoid creating unnecessary objects in hot paths:

// Bad: Creates new String each iteration
for (int i = 0; i < 10000; i++) {
    process(new String("constant"));  // Avoid
}

// Good: Reuse constant
private static final String CONSTANT = "constant";
for (int i = 0; i < 10000; i++) {
    process(CONSTANT);
}

Avoid Memory Leaks

Common leak patterns and fixes:

// Leak: Static collection grows unbounded
public class Cache {
    private static final Map<String, Object> cache = new HashMap<>();
    
    public static void put(String key, Object value) {
        cache.put(key, value);  // Never removed
    }
}

// DANGEROUS Fix: WeakHashMap alone is insufficient
// If 'value' holds strong reference to 'key', entry never gets cleared
private static final Map<String, Object> cache = new WeakHashMap<>();

// Proper Fix: Ensure no strong references from values to keys
private static final Map<String, WeakReference<Object>> cache = 
    new WeakHashMap<>();
// Or use specialized caches: Caffeine, Guava Cache, Chronicle Map

Proper Resource Management

// Use try-with-resources for Closeable resources
try (Connection conn = dataSource.getConnection();
     PreparedStatement stmt = conn.prepareStatement(sql);
     ResultSet rs = stmt.executeQuery()) {
    // Process results
}  // Auto-closed, no resource leak

Off-Heap Memory for Large Data

// For large caches, consider off-heap storage
ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024);  // 1MB off-heap

// Or use libraries like Chronicle Map, MapDB

Performance Analysis Tools

Command-Line Tools

jstat -gcutil <pid> 1000  # GC statistics every 1s
jmap -histo <pid>         # Object histogram
jcmd <pid> GC.heap_info   # Heap information
jcmd <pid> Thread.print   # Thread dump
jcmd <pid> VM.native_memory summary  # NMT analysis

Visual Tools

• JConsole: Basic monitoring, MBean inspection
• VisualVM: Profiling, heap dumps, thread analysis
• JDK Mission Control: Advanced profiling, JFR analysis
• Async Profiler: Low-overhead CPU and allocation profiling

Flight Recorder (JFR)

# Start recording
jcmd <pid> JFR.start name=profile duration=60s filename=recording.jfr

# Analyze with JDK Mission Control or jfr tool
jfr print recording.jfr

Quick Reference: GC Selection Matrix

Heap Size	CPUs	Latency Requirement	Recommended GC
< 2GB	< 2	Any	Serial
2GB - 4GB	Any	Throughput priority	Parallel
4GB - 16GB	Any	Balanced	G1 (default since JDK 9)
16GB+	Any	Low latency (< 10ms)	ZGC (JDK 15+) or Shenandoah

Getting Started

1. Baseline measurement: Enable GC logging before any tuning
2. Analyze current state: Use jstat and GC logs to identify issues
3. Size heap appropriately: Start with 50% of physical RAM, adjust based on working set
4. Select appropriate GC: Match to your latency/throughput requirements
5. Tune incrementally: Change one parameter at a time, measure impact
6. Monitor continuously: Production metrics reveal real-world behavior

# Minimal production configuration (Java 17+)
-Xms4g -Xmx4g \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=200 \
-XX:+UseContainerSupport \
-XX:NativeMemoryTracking=summary \
-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=10m