JVM Tuning Guide: Understanding GC, Memory Model, and Configuration Options

This article explains the principles and approaches for JVM performance tuning, focusing on understanding the JVM architecture, runtime data area, and execution engine components.

First understand the fundamentals before attempting any tuning; optimization requires balancing resources and goals.

The JVM consists of the execution engine (GC and JIT), class loading subsystem, JNI, and runtime data areas (heap and stack). Tuning mainly involves adjusting the runtime data area and selecting an appropriate garbage collector.

For JDK 1.8 the article provides a memory model overview and a set of JVM options for setting heap size, choosing GC algorithms, configuring parallel GC threads, enabling GC logs, setting metaspace size, thread stack size, and heap dump on OOM.

# Set heap memory
-Xmx4g -Xms4g
# Specify GC algorithm
-XX:+UseG1GC -XX:MaxGCPauseMillis=50
# Parallel GC threads
-XX:ParallelGCThreads=4
# GC logging
-XX:+PrintGCDetails -XX:+PrintGCDateStamps
# GC log file
-Xloggc:gc.log
# Max metaspace
-XX:MaxMetaspaceSize=2g
# Thread stack size
-Xss1m
# Heap dump on OOM
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local

The article categorizes garbage collectors into young‑generation (Serial, ParNew, Parallel Scavenge) and old‑generation (Serial Old, Parallel Old, CMS) and describes their characteristics, such as stop‑the‑world behavior, parallelism, and latency vs throughput trade‑offs.

Guidelines for GC selection are provided: use Parallel GC for throughput‑oriented workloads, CMS for low‑latency needs, and G1 for large heaps with moderate latency requirements; G1 becomes the default in JDK 9 and later.

It also notes that the default GC in JDK 8 is Parallel Scavenge (young) combined with Parallel Old (old), and highlights common interview questions about default GC settings.

Finally, the article advises monitoring, problem identification, result verification, and summarizing findings after tuning.