The Ultimate Java Performance Tuning Playbook: JVM Internals, GC Algorithms, and JIT Compilation in Production

1 Why Java Performance Still Matters in 2025

In 2025, Java remains one of the most deployed runtimes in production. From trading engines to Kubernetes microservices, Java powers billions of transactions daily. But despite ever-faster hardware, performance tuning still matters. Cloud costs scale linearly with inefficiency, and latency-sensitive systems can’t hide behind “just add more cores.” The JVM has evolved dramatically—new garbage collectors, smarter JIT compilers, and GraalVM’s ahead-of-time (AOT) capabilities have shifted the tuning landscape. Understanding these tools is the difference between “it works” and “it scales efficiently.”

1.1 The modern Java landscape

1.1.1 Java LTS and feature releases

The cadence of Java releases has stabilized: Long-Term Support (LTS) versions—Java 17, 21, and the upcoming 23—define what most production systems run. Each release has moved performance forward in tangible ways.

Java 17 cemented G1 GC as the default collector, making pause-time predictability the baseline rather than an afterthought. It introduced refinements to biased locking removal and sealed classes that improved JIT devirtualization opportunities.

Java 21 brought Generational ZGC, addressing the only remaining weakness of ZGC’s original design—handling short-lived objects efficiently. This was a major milestone for high-throughput services, letting developers combine sub-10 ms pause times with generational memory management.

Java 23 continues that trend with enhancements from JEP 477 (Shenandoah generational mode) and JEP 522 (G1 throughput optimizations), plus ongoing improvements to the tiered JIT pipeline. It’s not just about “faster GC” anymore—it’s about smarter, concurrent memory and code optimization.

1.1.2 HotSpot vs alternative JVM distributions

Not all JVMs are created equal. The HotSpot VM remains the reference implementation, but multiple distributions package and extend it for specific needs.

Eclipse Temurin (Adoptium): A community-driven, LTS-stable build with predictable behavior across OSes. Perfect for baseline production environments.
GraalVM CE/EE: Adds the Graal JIT compiler and optional AOT compilation (Native Image). The Graal compiler offers aggressive inlining and escape analysis, outperforming C2 in some workloads.
Vendor builds like Corretto (AWS), Zulu (Azul), or Liberica (BellSoft) may integrate vendor GC patches, NUMA tuning, or security hardening. Azul’s Prime builds even replace HotSpot’s JIT with Falcon, a custom compiler optimized for warmup speed and long-running throughput.

Choosing the right distribution affects startup, memory, and performance tooling compatibility. For example, GraalVM’s Native Image doesn’t support all reflection-heavy frameworks without configuration metadata, while Temurin guarantees spec compliance but no AOT.

1.1.3 The cloud and container shift

A decade ago, scaling a Java app meant adding RAM or a bigger EC2 instance. In today’s cloud-native world, that’s a cost liability. Containers constrain CPU and memory through cgroups, and oversizing pods multiplies waste across clusters.

Modern JVMs are container-aware—flags like -XX:+UseContainerSupport and -XX:MaxRAMPercentage=75 ensure heap sizing respects cgroup limits—but poor tuning still leads to memory pressure and throttling.

Cloud-native expectations (fast startup, low idle footprint, predictable p99 latency) also make cold-start performance critical. This is why projects like Spring AOT and GraalVM Native Image matter: they trade dynamic flexibility for startup and memory efficiency, ideal for scaling workloads or short-lived functions.

1.2 Performance goals and trade-offs

1.2.1 Throughput vs latency vs startup vs cost

Before tuning anything, you need to define your goal. These four axes rarely move together:

Throughput: Total operations per second—maximize CPU utilization.
Latency: Time per operation—especially p99/p999 behavior.
Startup time: Time to first request—critical for autoscaling and serverless.
Cost efficiency: CPU-seconds and memory per transaction.

For example, an API under heavy concurrency may tolerate minor throughput loss for tighter latency. A batch processor, on the other hand, can trade longer pauses for raw speed. Every tuning decision (GC type, JIT aggressiveness, heap size) optimizes one at the expense of others.

1.2.2 Tail latency and GC/JIT dominance

The p99 or p999 latency—the worst 1% or 0.1% of requests—defines perceived performance. These spikes often stem from JIT warmup or GC pauses, not business logic.

For instance, when a method crosses the compilation threshold, the JIT may trigger deoptimization or a stop-the-world compilation pause. Similarly, a poorly tuned G1 heap may trigger frequent mixed collections. Both events skew tail latency, even if average latency remains stable.

You can visualize this by enabling Java Flight Recorder (JFR) and plotting GC and JIT events against latency histograms. Often, optimizing allocation rate or warming up critical methods eliminates p99 spikes without changing code semantics.

1.2.3 When native images make sense

GraalVM Native Image compiles Java bytecode into a static binary, removing JIT warmup and shrinking startup to milliseconds. However, it comes with trade-offs:

Pros: Extremely fast startup, lower RSS, predictable latency, no JIT overhead.
Cons: Larger binaries, longer build time, no runtime profiling or dynamic classloading.

Native images shine in serverless or scale-to-zero environments (Spring Boot functions, Micronaut microservices) but underperform for long-running services where JIT can optimize hot paths better. As a rule of thumb: if uptime > 5 minutes and throughput matters more than startup, stick with HotSpot JIT.

1.3 A pragmatic tuning philosophy

1.3.1 “Measure, don’t guess”

Performance tuning without measurement is cargo cult engineering. Start with SLAs (what you promise), SLOs (what you target), and budgets (what you can spend). Collect real baselines—CPU time, allocation rate, GC pauses—using JFR and async-profiler under load.

Example:

java -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=profile.jfr -jar app.jar

Then analyze with JDK Mission Control to identify where time or memory goes. Your first tuning step should always be improving observability, not changing flags.

1.3.2 Safe tuning in production

Never tune blind. Roll out GC or JVM changes gradually—feature-flag them, or deploy canary instances.

For example, testing ZGC on 5% of production traffic helps validate pause-time improvement before full rollout. Tools like Spring Cloud Config, LaunchDarkly, or Kubernetes annotations let you toggle JVM options per environment safely.

1.3.3 Workflow of this playbook

This playbook follows a disciplined feedback loop:

Measure: Baseline with JFR, GC logs, metrics.
Hypothesize: Identify a bottleneck (GC, JIT, allocation).
Change: Adjust code or JVM settings.
Verify: Rerun under load, compare deltas.
Document: Record flags, environment, results.

Repeat until improvements plateau. This loop ensures you’re tuning empirically, not by superstition.

2 Inside the JVM: Execution Pipeline and Runtime Architecture

Understanding the JVM’s runtime pipeline is essential before tuning it. Every bytecode instruction flows through layers of interpretation, profiling, and machine code generation. Knowing where the time goes clarifies why some optimizations work—and others backfire.

2.1 From source to machine code

2.1.1 Compilation to bytecode and class loading

A .java file is first compiled into .class bytecode via javac. Each class is then loaded at runtime by a ClassLoader—which can be hierarchical (application, platform, bootstrap). The loader defines namespace boundaries, and mismanaging them (e.g., dynamic classloader leaks) often causes Metaspace OOMs.

2.1.2 The execution pipeline

When bytecode executes, HotSpot starts in interpreter mode, counting method invocations and branches. Once a method crosses a threshold (e.g., 10,000 invocations), it’s queued for JIT compilation.

C1 compiler (client tier): Produces fast, moderately optimized code. Ideal for warmup.
C2 compiler (server tier): Produces highly optimized machine code, leveraging profiling data.
Graal compiler: Replaces or complements C2 in modern builds, using an IR-based architecture that allows more advanced optimizations (escape analysis, vectorization).

Tiered compilation means code starts interpreted → C1 → C2 (or Graal) as it “heats up.” This balances startup time with peak throughput.

2.1.3 Deoptimization and On-Stack Replacement (OSR)

The JIT speculatively optimizes code assuming typical patterns (e.g., monomorphic call sites). If that assumption fails—say, a new subclass appears—the JVM deoptimizes back to interpreter mode. OSR allows long-running loops to be replaced mid-execution with optimized versions.

This dynamic adaptability is powerful but can hurt latency during transitions. Profilers like JITWatch visualize which methods are deoptimized and why.

2.2 HotSpot internals that matter for performance

2.2.1 Threads, safepoints, and stop-the-world pauses

The JVM coordinates threads through safepoints—moments when all threads reach a consistent state, allowing GC, deoptimization, or class redefinition. Safepoints cause stop-the-world pauses, even in “concurrent” collectors.

You can measure safepoint time via JFR or flags:

-XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics

If safepoint pauses dominate, it may indicate too frequent GC or excessive class redefinitions (common in frameworks using dynamic proxies).

2.2.2 Object layout, headers, and compressed oops

Each Java object carries a header (mark word + class pointer). On 64-bit JVMs, compressed oops pack references into 32 bits to save memory when heaps <32 GB. This improves cache locality.

You can inspect object size with JOL (Java Object Layout):

System.out.println(ClassLayout.parseClass(MyClass.class).toPrintable());

This tool reveals actual object footprints, alignment padding, and header sizes—crucial when optimizing high-allocation data structures (e.g., switching ArrayList to primitive buffers).

2.2.3 The Java Memory Model and performance

The Java Memory Model (JMM) guarantees visibility and ordering. From a performance standpoint, these guarantees imply fences that can limit reordering or caching. False sharing—two threads updating adjacent fields on the same cache line—can tank performance.

Using @Contended (with -XX:-RestrictContended) or structuring objects to avoid cache-line overlap can improve multi-threaded throughput by reducing cache coherence traffic.

2.3 GraalVM architecture and where it fits

2.3.1 GraalVM as a JDK distribution

GraalVM integrates three key layers:

Graal JIT compiler: A Java-based optimizing compiler that replaces C2.
Polyglot runtime: Executes multiple languages (JavaScript, Python, R, LLVM).
Native Image: Compiles applications ahead of time into native binaries.

The Graal compiler offers better inlining and escape analysis than C2 for dynamic workloads, though warmup can be slower due to JVM-based compilation.

2.3.2 JVM mode vs Native Image mode

Mode	Startup	Peak Throughput	Memory	Observability
JVM (JIT)	Slow warmup	High	Higher RSS	Full (JFR, profilers)
Native Image (AOT)	Instant	Lower	Smaller	Limited

The decision depends on workload profile. APIs with bursty traffic benefit from AOT; continuously running microservices still favor the JVM mode’s adaptive optimization.

2.3.3 Direction of GraalVM

Oracle’s roadmap increasingly focuses on Native Image and polyglot interoperability. For pure Java, Graal’s JIT remains valuable but less prioritized than AOT. In production, expect GraalVM to excel for serverless and edge deployments, while HotSpot continues dominating backend services.

2.4 Tooling and libraries

2.4.1 JOL (Java Object Layout)

JOL helps you reason about memory alignment and padding—especially when optimizing collections or struct-like objects. For example, analyzing an AtomicLong array can reveal false-sharing issues between adjacent counters.

2.4.2 JITWatch

JITWatch parses -XX:+PrintCompilation logs, showing which methods were inlined, optimized, or deoptimized. It’s invaluable when investigating why a “hot” method never gets compiled to native code.

2.4.3 perf-map-agent and async-profiler

For native call stacks, combine perf-map-agent with async-profiler to generate accurate flame graphs:

./profiler.sh -d 60 -e cpu -f profile.html <pid>

This avoids safepoint bias and gives visibility into both Java and native frames.

3 Java Memory and Garbage Collection Fundamentals

Memory management defines how well your JVM scales. GC isn’t just a background process—it directly affects throughput, latency, and cost.

3.1 Java heap and non-heap memory

3.1.1 Heap regions, generations, and metaspace

The heap is divided into young (Eden + survivor) and old generations. Young GC handles short-lived objects; old GC deals with survivors. The Metaspace stores class metadata, dynamically sized outside the heap.

3.1.2 Thread stacks and off-heap memory

Each thread has a native stack (controlled by -Xss). Frameworks like Netty and Chronicle allocate direct buffers off-heap to avoid GC pressure. Monitor these via Native Memory Tracking:

-XX:NativeMemoryTracking=summary

Off-heap leaks (e.g., unfreed ByteBuffers) bypass GC entirely and can exhaust native memory.

3.1.3 Common memory failure modes

OutOfMemoryError: Java heap space – true heap exhaustion.
OutOfMemoryError: Metaspace – classloader leaks from reloading.
Native OOMs – untracked off-heap or thread stack exhaustion.

Tools like Eclipse MAT help identify retained objects and classloader chains behind leaks.

3.2 The GC problem space

3.2.1 Allocation rates and object lifetime

GC efficiency depends on allocation rate (bytes/sec) and object lifetime distribution. Most objects die young—this is why generational collectors work. But frameworks that pool objects (e.g., Netty’s buffers) can defeat this assumption, increasing promotion to old gen.

3.2.2 Safepoints and barriers

GC coordination happens via safepoints. Write and read barriers track object references during concurrent phases. Low-pause GCs (ZGC, Shenandoah) minimize stop-the-world time by making barriers cheaper and more fine-grained.

3.2.3 GC logs and unified logging

Enable GC logs with:

-Xlog:gc*:file=gc.log:tags,uptime,level,timestamps

Modern unified logging (JEP 158) standardizes output. Analyzing allocation rate, pause time, and promotion trends quickly reveals whether GC pressure or heap sizing causes slowdowns.

3.3 The HotSpot collector zoo in 2025

3.3.1 Serial and Parallel collectors

Still useful for small heaps or batch jobs where latency is irrelevant. Parallel GC maximizes throughput by dedicating threads to GC, but pauses grow with heap size.

3.3.2 G1 GC (default)

G1 splits the heap into regions, mixing young and old collections. It uses remembered sets to track cross-region references. The key tuning knob is:

-XX:MaxGCPauseMillis=200

This expresses your pause-time target, letting G1 balance mixed vs full collections.

3.3.3 Low-pause GCs: ZGC and Shenandoah

Both are region-based concurrent collectors. ZGC uses colored pointers to track object relocation, achieving <10 ms pauses even on terabyte heaps. Shenandoah uses Brooks forwarding pointers to similar effect, with slightly higher CPU cost but simpler design.

3.3.4 Generational ZGC in JDK 21+

The introduction of Generational ZGC brought young/old separation into ZGC, drastically improving performance for allocation-heavy workloads (e.g., JSON parsing or reactive streams). It combines concurrent relocation with generational heuristics—often outperforming G1 even at moderate heap sizes.

3.4 Choosing the right GC for your workload

3.4.1 Heuristics

GC	Heap Size	Latency	CPU	Use Case
Serial	<1 GB	High	Low	Small apps, tests
G1	1–64 GB	Medium	Moderate	General-purpose
ZGC	>4 GB	Very low	Moderate	Latency-critical
Shenandoah	>8 GB	Very low	Higher	Large multi-threaded

3.4.2 Workload archetypes

Batch/ETL: Max throughput → Parallel or G1.
Low-latency API: Stable tail latency → ZGC.
Streaming/analytics: Concurrent allocation → Shenandoah or Generational ZGC.

3.4.3 Containers and Kubernetes

In containerized environments, respect cgroups:

-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

Avoid hardcoding -Xmx larger than container limits. For oversubscription, prefer G1 or ZGC—they adapt better under constrained memory than Parallel GC.

3.5 Helpful tools and libraries

3.5.1 GC log analyzers

GCeasy, GCViewer, and GarbageCat visualize pause distributions and promotion rates. Integrate them in CI/CD pipelines to detect GC regressions automatically.

3.5.2 Leak detection helpers

Use Eclipse MAT or YourKit to analyze heap dumps. Combine with JFR event correlation to identify leaking allocations over time.

3.5.3 Libraries reducing allocation pressure

Libraries like Agrona, Chronicle Queue, and LMAX Disruptor reduce GC pressure by using off-heap or preallocated data structures. Example:

RingBuffer<Event> ringBuffer = new RingBuffer<>(Event::new, 1024);

These designs minimize object churn—crucial when every allocation risks a GC cycle.

4 G1GC vs ZGC vs Shenandoah: Deep Dive & Tuning

In real systems, garbage collection behavior is often the main factor behind unpredictable latency or CPU spikes. While modern collectors have become remarkably efficient, each has trade-offs that must align with your workload’s allocation pattern, pause-time budget, and hardware profile. G1, ZGC, and Shenandoah all manage memory in regions and run concurrent phases, but the details of how they move objects and coordinate threads differ dramatically. Understanding these differences is key to stable performance.

4.1 G1 GC in depth

4.1.1 Region layout, young/old sets, remembered sets, mixed collections

G1 (Garbage-First) divides the heap into uniform regions (1–32 MB). It tracks “young” and “old” regions separately rather than having contiguous generations. The collector maintains remembered sets—small tables that record references from one region to another—allowing it to collect parts of the heap without scanning it all.

Each GC cycle starts with a young collection, copying objects from Eden to survivor and sometimes promoting to old regions. When old generation occupancy crosses a threshold, G1 schedules mixed collections, which reclaim both young and some old regions concurrently. The goal is to meet the target pause time (MaxGCPauseMillis) while keeping fragmentation low.

Because regions can be collected independently, G1 scales better on multi-core systems. But remembered sets come with CPU and memory overhead, so tuning region size and pause targets is essential.

4.1.2 Key tuning knobs

Several flags control G1’s behavior. The most impactful are:

-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
-XX:G1HeapRegionSize=8m

MaxGCPauseMillis defines your latency budget; G1 adjusts collection effort to meet it.
InitiatingHeapOccupancyPercent decides when concurrent marking starts. Lower values trigger earlier marking, reducing full-GC risk.
G1HeapRegionSize sets region size; larger regions reduce remembered-set overhead but can inflate pause times for huge objects.

Watch for humongous objects—those exceeding half a region. They bypass normal allocation and occupy entire regions, causing fragmentation. Splitting large arrays or switching to off-heap buffers often mitigates this.

4.1.3 Recent improvements (JEP 522)

JEP 522 in JDK 23 optimized remembered-set handling, cutting CPU overhead in high-throughput applications. The improvements reduce synchronization around remembered-set updates and improve concurrency during mixed collections. The result is measurable: in typical server workloads, throughput gains of 10–15% and shorter young-GC pauses have been observed without changing configuration.

For production JVMs running Java 17 or earlier, upgrading to Java 21+ yields immediate performance benefits even before flag tuning, simply due to these internal enhancements.

4.1.4 Real-world scenario: tuning a Spring Boot monolith

A Spring Boot API with 8 GB heap was experiencing 2–3 second full GCs every few hours. GC logs revealed back-to-back mixed collections failing to meet the pause goal, followed by full compaction. Key observations:

Allocation rate: ~200 MB/s
Old-gen occupancy >80%
Frequent humongous object warnings

Initial GC log:

[info][gc] GC(423): Pause Full (G1 Compaction) 2100ms

Tuning steps:

Reduced humongous objects by splitting JSON buffers.
Set -XX:MaxGCPauseMillis=100 and -XX:InitiatingHeapOccupancyPercent=35 to trigger earlier concurrent marking.

Enabled logging:

-Xlog:gc*,safepoint:file=gc.log:time,level,tags

Verified in JFR that concurrent phases completed before heap pressure rose again.

Result: Full GCs dropped to zero; mixed collections averaged 120 ms, and 99th percentile latency stabilized. The lesson—G1 performs best when concurrent marking starts early and humongous allocations are controlled.

4.2 ZGC internals and tuning

4.2.1 Region-based, concurrent, colored pointers

ZGC takes concurrency further. It divides memory into relocation regions and performs almost all operations concurrently with the application. The key innovation is colored pointers: each object reference encodes metadata bits indicating its marking and relocation state. This allows the collector to move objects while threads continue running without global safepoints.

Typical pause times stay under 10 ms, even on multi-terabyte heaps. Only a few brief synchronization points remain (root scanning, relocation setup). This predictability makes ZGC ideal for trading, gaming, and real-time APIs.

4.2.2 Generational vs non-generational modes

Early ZGC versions were non-generational, treating all objects equally. That limited throughput because short-lived allocations still required concurrent marking. Java 21 introduced Generational ZGC, separating young and old regions while retaining concurrent relocation. Young collections are cheaper, and old objects are compacted less frequently.

Switching to generational mode is as simple as:

-XX:+UseZGC -XX:+ZGenerational

In tests with high allocation rates (>500 MB/s), generational ZGC cut total GC CPU by 25–40%. It also reduced write-barrier traffic because fewer objects needed concurrent remapping.

4.2.3 Core tuning flags

ZGC requires minimal tuning, but a few parameters are useful for fine control:

-XX:+UseZGC
-XX:+ZGenerational
-XX:SoftMaxHeapSize=8g
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=4

SoftMaxHeapSize sets a target footprint smaller than the physical heap; ZGC will try to stay below it unless pressured.
ConcGCThreads and ParallelGCThreads let you balance GC parallelism vs CPU cost.
NUMA awareness (-XX:+UseNUMA) helps on multi-socket servers by keeping allocations local to CPU nodes.

Monitoring jcmd GC.heap_info shows real-time heap usage and relocation progress.

4.2.4 Real-world scenario: migrating to ZGC

A high-throughput market data service processing 300k events/sec ran on Java 17 with G1. Tail latency at p99.9 hovered near 250 ms due to frequent mixed collections. After migrating to Java 21 with ZGC (generational mode):

Startup time increased slightly (by ~15%), but steady-state latency dropped.
Pauses averaged 3.4 ms, even under 500 MB/s allocation rates.
CPU usage rose by ~5% because of concurrent barriers, but the service could sustain higher request concurrency with less jitter.

JFR showed minimal time in safepoints and stable heap occupancy. This demonstrates how ZGC trades small background CPU overhead for near-constant pause times—ideal for low-latency systems.

4.3 Shenandoah internals and tuning

4.3.1 Brooks pointers, concurrent compaction and region layout

Shenandoah shares ZGC’s goal—pause times under 10 ms—but takes a different approach. It embeds a Brooks forwarding pointer in each object header, which redirects old references to relocated copies. This allows compaction to run fully concurrently, though it costs a single pointer dereference per access.

Regions are collected independently, with concurrent marking, evacuation, and reference updates. Because compaction is concurrent, pause time remains nearly constant as the heap grows.

4.3.2 Heuristics: adaptive, static, compact

Shenandoah uses heuristics to decide when and how aggressively to collect.

Adaptive (default): balances GC effort against allocation pressure.
Static: fixed triggers, useful for predictable workloads.
Compact: more aggressive compaction to combat fragmentation.

Switch heuristics with:

-XX:ShenandoahGCHeuristics=compact

Adaptive is best for most services, but compact helps for long-lived heaps with fragmented old regions.

4.3.3 Tuning for big heaps

For heaps above 32 GB, thread counts and pacing become crucial. Example configuration:

-XX:+UseShenandoahGC
-XX:ShenandoahGCHeuristics=adaptive
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=6
-XX:ShenandoahUncommitDelay=300000

ShenandoahUncommitDelay controls how long unused regions stay reserved—reducing RSS in elastic environments. Monitoring via jstat -gcutil or JFR confirms when cycles begin and finish.

Shenandoah’s pause time scales with the number of root references, not heap size. In large-memory analytics systems, you’ll see near-flat pause durations even as data sets grow.

4.3.4 Real-world scenario: data platform migration

A JVM-based analytics platform on Red Hat OpenJDK (48 GB heap) suffered 1–2 s pauses under G1. After switching to Shenandoah with adaptive heuristics:

Mean pause dropped to 8–12 ms.
CPU rose by ~10% during concurrent phases, but throughput stayed flat.
Long-term fragmentation reduced because compaction ran continuously.

Developers tuned ShenandoahFreeThreshold=15 to trigger earlier concurrent marking and used JFR to verify concurrent evacuation coverage. The migration yielded predictable tail latency, enabling tighter SLAs for interactive dashboards.

4.4 Comparing G1, ZGC, and Shenandoah

4.4.1 Microservices on Kubernetes

For pods with 2–8 GB heap and fast autoscaling, G1 remains the pragmatic default. Its pause goals fit microservice latency targets (<200 ms), and it respects container limits automatically. ZGC’s benefits appear mainly above 4 GB heap or when p99 latency is critical. Shenandoah is attractive for Red Hat or Fedora deployments, but ZGC is generally more efficient in small heaps.

A rule of thumb:

G1: balanced and predictable.
ZGC: consistent low latency.
Shenandoah: flexibility and fast compaction.

4.4.2 Large JVM services

For heaps above 100 GB, ZGC dominates. Its relocation algorithm scales nearly linearly with heap size, and colored pointers avoid global stops. Shenandoah performs similarly but with slightly higher per-access overhead. G1 struggles beyond 64 GB because remembered sets consume too much memory and pause predictability degrades.

4.4.3 Hybrid workloads

Many real systems mix latency-sensitive request handling with periodic heavy computation (batch, cache rebuilds). Here, G1 often remains the middle ground—tunable between throughput and pause time. For tighter SLAs or 24/7 APIs, ZGC’s constant pauses justify the small CPU premium.

4.4.4 Cost analysis

In the cloud, GC choice affects CPU time and therefore cost. ZGC may use 5–10% more CPU under constant load, but avoiding tail-latency retries or timeouts often offsets that. G1’s lower background cost can win in steady batch workloads. For organizations billed by CPU-seconds, quantifying the trade-off via metrics like cost per 10⁶ requests clarifies ROI.

5 JIT Compilation, Tiering & Code-Level Optimizations

Understanding GC only solves half the performance equation. The other half lives in the Just-In-Time (JIT) compiler—where bytecode turns into optimized machine instructions. The JIT’s decisions about inlining, escape analysis, and loop unrolling can make the difference between 80% and 98% CPU efficiency.

5.1 Tiered compilation explained

5.1.1 C1 vs C2 vs Graal compiler

HotSpot has two main JIT compilers:

C1 (client): Fast, low-optimization compiler for warmup.
C2 (server): Produces highly optimized machine code for long-running hot paths.
Graal: A modern, IR-based replacement that often matches or exceeds C2 on complex workloads.

Tiered compilation allows the JVM to start fast (C1) and gradually recompile hot methods with C2 or Graal.

5.1.2 Tiered compilation pipeline

The execution stages are:

Interpretation – collect profiling data.
C1 compilation – insert inline caches, lightweight optimizations.
C2/Graal compilation – aggressive inlining, loop vectorization.

Thresholds can be adjusted:

-XX:TieredStopAtLevel=1     # Disable C2
-XX:CompileThreshold=10000  # Adjust method hotness

Most production systems leave defaults, but tuning thresholds can help short-lived applications reach optimal code faster.

5.1.3 Reading compilation logs

Enable compilation tracing:

-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining

The output shows when methods compile and why they inline (or not). Pair this with JITWatch to visualize the hierarchy and identify missed opportunities.

5.2 Key optimizations that change performance

5.2.1 Inlining

Inlining replaces method calls with their bodies. It removes call overhead and exposes further optimization opportunities. But excessive inlining bloats code and increases instruction-cache misses.

Incorrect:

public interface PriceCalculator { decimal compute(decimal x); }

High polymorphism (many implementations) prevents inlining. Correct: seal hierarchies or use records to make call sites monomorphic.

5.2.2 Escape analysis

Escape analysis detects whether an object can be stack-allocated instead of on the heap.

Example:

decimal compute() {
    var p = new Point(1, 2);
    return p.X + p.Y;
}

Here Point doesn’t escape, so JIT allocates it on the stack or even eliminates it entirely (scalar replacement). However, passing it to another thread or lambda prevents this.

5.2.3 Loop optimizations

The JIT performs loop unrolling and bounds-check elimination. Writing loops with predictable termination helps:

for (int i = 0; i < array.Length; i++) sum += array[i];

The JIT removes range checks when it proves i stays within bounds. Avoid modifying loop limits dynamically; that disables optimization.

5.2.4 Devirtualization and polymorphism

When a call site is monomorphic (one target type), JIT can inline it directly. Polymorphic sites (e.g., List vs LinkedList) prevent this. Using sealed classes or pattern matching (in Java 21) reduces polymorphism, improving devirtualization.

5.3 JIT pitfalls in real-world code

5.3.1 Highly polymorphic call sites

Frameworks using reflection (like Jackson or Hibernate) generate megamorphic call sites. These resist inlining. Replacing them with code-generated mappers (e.g., DSL-JSON) or sealed hierarchies often doubles throughput.

5.3.2 Reflection and dynamic proxies

Reflection disables most JIT optimizations. Prefer MethodHandle or bytecode generation:

import types
def dynamic_call(fn):
    return types.MethodType(fn, object)

In Java, using MethodHandles.lookup() provides faster dynamic invocation than reflection.

5.3.3 Code cache exhaustion and compilation storms

Each compiled method consumes native code cache space (default ~240 MB). Large applications with thousands of hot methods can exhaust it, forcing deoptimizations. Increase cache size with:

-XX:ReservedCodeCacheSize=512m

Monitor CodeCache JFR events for saturation.

5.4 Practical techniques and tools

5.4.1 JITWatch visualization

Feed compilation logs to JITWatch to see which methods were optimized. This identifies cold code bloating your binaries or hot loops that never reach tier 4 compilation.

5.4.2 async-profiler + JFR flame graphs

Use async-profiler together with JFR to correlate CPU time and JIT status:

./profiler.sh -d 30 -e cpu -f cpu.html <pid>

Overlay JIT states to find hot methods still interpreted—often the cause of sudden latency after redeployment.

5.4.3 Benchmarking with JMH

JMH isolates JIT warmup from steady state. Example benchmark:

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
public void parseJson() {
    objectMapper.readValue(json, Data.class);
}

Run with -prof gc to measure allocation rate. JMH ensures you compare optimized code, not cold-start performance.

5.5 GraalVM and Native Image specifics

5.5.1 Ahead-of-time compilation

GraalVM’s Native Image eliminates JIT warmup entirely by compiling ahead of time. It performs aggressive inlining but loses runtime profiling, so some optimizations (like speculation-based devirtualization) disappear. This yields faster startup but sometimes 10–20% lower peak throughput.

5.5.2 Configuration and reachability metadata

AOT builds require reflection metadata for dynamic features. Spring AOT and Micronaut handle this automatically, but custom frameworks may need manual JSON configs:

[
  {"name": "com.example.MyClass", "allDeclaredConstructors": true}
]

Without it, unreachable classes are removed, causing NoSuchMethodException at runtime.

5.5.3 Real-world example: converting a Spring Boot service

A Spring Boot REST API moved from HotSpot to GraalVM Native Image. Startup dropped from 5.2 s to 250 ms, RSS from 600 MB to 220 MB. However, peak throughput fell ~12% under sustained load. By precomputing JSON serializers and reducing reflection, the team narrowed the gap to <5%. For scale-to-zero workloads, the trade was worth it.

6 Observability, JFR & Low-Overhead Production Profiling

Once your JVM is tuned, the next challenge is maintaining performance under real-world conditions. You can’t optimize what you can’t observe. Traditional profilers are too invasive for production, so the focus shifts to low-overhead observability—tools that collect granular data continuously without distorting behavior. Java Flight Recorder (JFR) sits at the center of this, giving you fine-grained insight into the runtime with less than 1% overhead.

6.1 Why traditional profilers fail in production

6.1.1 High overhead, safepoint bias, and distorted results

Classic profilers rely on bytecode instrumentation or agent hooks that intercept every method call. This adds measurable CPU and latency overhead—often 10–50%. Even sampling profilers can distort results if they pause threads at safepoints. Because many safepoints coincide with GC or JIT activity, samples become biased toward those states, overstating their cost.

For example, a naive CPU sampler might report 40% GC time simply because the profiler paused during safepoint checks. Production-safe profiling demands asynchronous stack sampling, where thread stacks are read without interrupting execution. Tools like async-profiler or JFR use this approach to gather accurate call stacks at native level.

6.1.2 Sampling vs instrumentation

Instrumentation measures every event directly—precise but costly. Sampling captures snapshots periodically—approximate but efficient. The right choice depends on context.

Instrumentation works well for targeted scenarios, like timing a specific method in a microbenchmark:

var sw = Stopwatch.StartNew();
service.ProcessBatch();
Console.WriteLine($"Duration: {sw.ElapsedMilliseconds} ms");

In production, you want aggregated patterns, not per-call timing. Sampling profilers collect thousands of stack traces per second, allowing statistical analysis of hot paths. The trade-off: you lose micro-level precision but gain holistic accuracy at scale.

6.1.3 The danger of “profiling the profiler”

Running multiple profilers simultaneously can create self-referential noise. Instrumentation agents might interfere with JFR or async-profiler, skewing results. Even lightweight agents like -agentlib:jdwp (for debugging) alter thread scheduling and JIT timing. Always isolate profiling sessions—one profiler at a time—and benchmark with and without instrumentation to measure overhead explicitly.

6.2 Java Flight Recorder (JFR) & JDK Mission Control (JMC)

6.2.1 JFR basics: events, recordings, profiles and templates

JFR is built into the JVM itself. It records events such as method samples, GC pauses, allocation rates, lock contention, and thread state changes. Each recording is a binary log that can be analyzed offline or streamed to monitoring systems.

You can start a recording at launch:

java -XX:StartFlightRecording=filename=app.jfr,duration=60s,settings=profile -jar app.jar

Or start dynamically via jcmd:

jcmd <pid> JFR.start name=prod_record settings=profile duration=120s filename=recording.jfr

Templates define what’s captured—default, profile, or custom XML profiles that trade detail for lower overhead.

6.2.2 Enabling JFR in production

In production, you can run continuous or rolling recordings. Rolling mode keeps a fixed buffer size, overwriting old data:

-XX:StartFlightRecording=name=rolling,settings=default,maxsize=512m,maxage=30m,filename=/var/logs/app.jfr

This allows you to retrieve recent runtime history after an incident without always-on logging overhead. On-demand recordings are useful for diagnosing transient spikes—triggered manually or through automation (e.g., when latency exceeds a threshold).

6.2.3 Using JMC to analyze JFR

JDK Mission Control (JMC) visualizes JFR recordings. Key panels include:

Method profiling: shows top methods by CPU time.
Allocation flame graph: identifies where objects are created.
GC view: correlates pause duration with heap regions.
Locking view: pinpoints threads waiting on monitors.

A practical workflow: open a .jfr file, filter for “p99 latency spike window,” and cross-check the Threads and GC tabs. If GC pauses align with request spikes, tuning heap or switching collectors may help. If CPU is saturated, the Method Profiling tab reveals true bottlenecks.

6.3 Always-on profiling with JFR metrics & external APM

6.3.1 JFR-based telemetry in observability platforms

Modern APMs like New Relic, Datadog, and Elastic APM integrate JFR directly. Instead of pulling data through agents, they stream JFR metrics (allocation rate, GC time, safepoint duration) to their dashboards.

Example snippet for New Relic JFR daemon config:

java -XX:+FlightRecorder \
     -XX:StartFlightRecording:settings=default,delay=10s,filename=telemetry.jfr \
     -javaagent:newrelic.jar \
     -jar app.jar

This gives high-resolution JVM telemetry without custom instrumentation, letting you correlate GC and JIT data with application-level traces.

6.3.2 Combining JFR with Micrometer, Prometheus, and Grafana

For self-hosted observability, Micrometer bridges JVM metrics to Prometheus. Combine it with JFR metrics for deeper insight:

MeterRegistry registry = new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);
new JvmMemoryMetrics().bindTo(registry);
new JvmGcMetrics().bindTo(registry);

Prometheus scrapes the metrics endpoint, while Grafana visualizes GC pause trends, code cache utilization, and allocation throughput. Overlaying JFR-derived latency traces on business metrics makes root-cause correlation immediate.

6.3.3 Alerting on GC/JIT/JFR metrics

Set alerts on leading indicators, not failures:

Allocation rate > expected baseline → potential leak.
Safepoint time > 5% of wall clock → GC/JIT thrashing.
Code cache utilization > 90% → JIT nearing capacity.

Grafana example query:

avg_over_time(jvm_gc_pause_seconds_sum[5m]) > 0.2

Trigger a JFR recording when this condition persists for several minutes, then analyze before performance degrades further.

6.4 Complementary tools & libraries

6.4.1 async-profiler and its integrations

async-profiler uses native signals to sample stacks asynchronously, avoiding safepoint bias. It produces flame graphs directly:

./profiler.sh -d 60 -e cpu -f cpu.html <pid>

You can integrate it with JFR (-XX:+UnlockDiagnosticVMOptions -XX:+ProfileVM) to embed CPU samples directly into recordings. Tools like FlameScope visualize both kernel and user-space frames, helping identify lock contention or misbehaving JNI code.

6.4.2 Java profilers: YourKit, JProfiler, VisualVM

When deeper analysis is needed outside production, desktop profilers remain valuable:

YourKit: comprehensive memory analysis, allocation flame graphs.
JProfiler: smooth IDE integration and SQL/HTTP trace correlation.
VisualVM: free, lightweight option for staging environments.

Use them to confirm hypotheses from JFR traces rather than as primary production profilers.

6.4.3 Application-level telemetry

Combine runtime insight with application metrics using Spring Boot Actuator and OpenTelemetry:

management.endpoints.web.exposure.include=health,metrics,info,env
management.metrics.export.otlp.enabled=true

Export runtime and request metrics together, creating a unified performance picture across infrastructure, JVM, and code layers.

6.5 Hands-on example: Diagnosing a production latency regression

6.5.1 Symptom: p99 spikes during traffic bursts

A payment service deployed on Java 21 showed 20× p99 latency spikes during traffic bursts, despite stable average latency. CPU usage stayed flat, ruling out thread starvation. Suspect areas included GC or lock contention.

6.5.2 Capturing a focused JFR recording

To minimize overhead, the team started an on-demand JFR recording:

jcmd <pid> JFR.start name=spike window settings=profile duration=120s filename=spike.jfr

They triggered it via automation when request latency exceeded 500 ms for more than one minute.

6.5.3 Analyzing JFR to distinguish root cause

In JMC, they filtered events for the spike window. GC view showed several 80 ms pauses, but allocation rate remained normal. Thread dump analysis revealed ReentrantLock contention inside the metrics collector—indicating synchronized access around a shared registry.

The flame graph confirmed 40% CPU time in MicrometerMeterRegistry.writeMetrics() during spikes. GC wasn’t the cause; a locking hotspot was.

6.5.4 Implementing and verifying the fix

Developers replaced the synchronized map with a lock-free structure:

ConcurrentHashMap<String, Metric> registry = new ConcurrentHashMap<>();

They redeployed with -XX:+UseZGC to ensure minimal pause interference, then repeated the same load test. JFR showed safepoint time under 0.5% and lock contention events near zero. p99 latency dropped from 600 ms to 45 ms under load.

Finally, they automated regression detection by triggering JFR-on-alert in Prometheus when latency exceeded 2× baseline. Over time, this became part of the team’s performance playbook, ensuring visibility before issues impact production SLAs.

7 The Step-by-Step Performance Tuning Playbook

When performance issues appear, the worst response is to start guessing JVM flags or rewriting random parts of the code. Tuning should follow a consistent, measurable process—from defining what “fast enough” means to capturing evidence, implementing changes, and validating results. The following playbook outlines that repeatable cycle.

7.1 Stage 1 – Understand the problem

7.1.1 Defining performance requirements

Every optimization starts with explicit goals. Without defined SLAs (Service Level Agreements) or SLOs (Service Level Objectives), “slow” becomes subjective. Quantify:

Latency targets: e.g., 99th percentile ≤ 200 ms for REST APIs.
Throughput goals: e.g., process 10 K events/sec with <80% CPU.
Startup budget: e.g., cold start < 3 s for autoscaling microservices.
Resource budgets: e.g., each pod ≤ 2 GB RAM, ≤ 1 vCPU.

Equally important is defining “good enough.” A 10% improvement may not justify a week of tuning if latency already meets SLA. The aim is predictable, efficient performance—not absolute perfection.

7.1.2 Collecting context

Performance lives in context. Gather the full stack view before touching code:

Infrastructure: CPU model, NUMA layout, container limits, network type.
Java runtime: vendor distribution (Temurin, GraalVM), version (17/21/23).
GC type: confirm via logs or jcmd GC.class_histogram.
Framework stack: Spring Boot, Quarkus, Netty, or custom.
Traffic patterns: steady vs bursty, I/O bound vs CPU bound.

For distributed systems, map dependencies and data paths. A latency spike might come from an external API or database before the JVM is even involved.

7.1.3 Establishing baselines

Never tune without a baseline. Use synthetic microbenchmarks for isolated code paths and load tests for system behavior under pressure.

Microbenchmark example with JMH:

@Benchmark
@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
public void parseJson() {
    mapper.readValue(sample, Data.class);
}

System-level load test using Gatling (Scala DSL):

val scn = scenario("API Load")
  .exec(http("GET /orders").get("/orders"))
setUp(scn.inject(rampUsers(2000) during (30 seconds)))

Collect metrics for CPU, GC, latency distribution, and memory footprint. Record GC logs and JFR traces during the baseline run. These become your reference points for measuring change impact later.

7.2 Stage 2 – Measure & attribute

7.2.1 Instrumentation strategy

Modern systems rely on layered observability: metrics, logs, traces, and profiles.

Metrics show trends (e.g., GC pause ratio, throughput).
Logs capture discrete events.
Traces (OpenTelemetry) reveal request paths.
Profiles show CPU or memory usage per method.

Use a consistent naming convention across all of them. For example, expose the same operation ID in metrics labels and trace spans. This makes cross-correlation trivial during analysis.

7.2.2 Building a unified view with JFR + async-profiler + APM

Combine JFR for low-overhead JVM telemetry with async-profiler for CPU hotspots and your APM (like Datadog or Grafana Cloud) for distributed context.

Example diagnostic stack:

# Start async-profiler in parallel with JFR
jcmd <pid> JFR.start name=baseline settings=profile filename=baseline.jfr
./profiler.sh -d 60 -e cpu -f cpu.html <pid>

In practice:

Use JFR for JVM-level patterns (GC, JIT, allocation).
async-profiler for CPU call stacks.
APM for external latency (database, network).

Overlaying these data sources turns scattered observations into causality—e.g., “CPU spike caused by JSON serialization” or “tail latency tied to mixed G1 collections.”

7.2.3 Separating GC, JIT, and code costs

Attribution is key. CPU time spent in GC, JIT compilation, or synchronization shouldn’t be confused with business logic.

Use JFR event categories:

GarbageCollection: gc_pause, gc_cpu_time.
Compiler: compilation_time, deoptimization.
Threading: park, monitor_enter, lock_instance.

Compare total wall time to sum of these categories. Anything remaining is true application logic. This prevents false conclusions like “method X is slow” when the culprit is GC promotion pauses.

7.3 Stage 3 – Low-hanging fruit in code & configuration

7.3.1 Fixing N+1 queries and chatty I/O

Databases and remote calls dominate latency. Typical anti-pattern:

foreach (var id in ids)
    orders.Add(repo.GetOrder(id)); // N+1 query problem

Correct approach:

orders = repo.GetOrdersByIds(ids); // single batch call

The same applies to REST APIs and message brokers—batch or pipeline requests whenever possible. Use connection pooling and asynchronous I/O to avoid blocking threads.

7.3.2 Reducing allocations in hot paths

String concatenation, JSON parsing, and collection resizing are silent performance killers. Replace naive patterns with reusable buffers or stream APIs.

// Inefficient
var sb = new StringBuilder();
foreach (var item in list) sb.Append(item.ToString());

// Efficient
var joined = string.Join(',', list);

Use libraries like DSL-JSON or Jackson Afterburner for zero-copy deserialization, and prefer primitive collections from fastutil or Agrona in tight loops.

7.3.3 Tuning thread pools

Right-sized pools prevent context-switch thrash. Measure queue depth and utilization; then adjust pool size:

ThreadPoolExecutor exec = new ThreadPoolExecutor(
    8, 32, 60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000)
);

For async frameworks (Project Reactor, CompletableFuture), tune schedulers via Schedulers.newBoundedElastic() or adjust fork-join pool parallelism:

-Djava.util.concurrent.ForkJoinPool.common.parallelism=8

7.3.4 Library choices for performance

Use frameworks designed for your latency budget:

Async I/O: Netty, Vert.x, or Spring WebFlux outperform blocking Tomcat for concurrent I/O.
Low-latency messaging: LMAX Disruptor, Chronicle Queue, or Agrona RingBuffer avoid GC churn via preallocated buffers.
Serialization: DSL-JSON and Jackson Afterburner outpace Gson or JSON-B by 2–5× on throughput.

Benchmark under your workload before adopting; theoretical speed doesn’t always translate when integrated with your stack.

7.4 Stage 4 – JVM & GC tuning

7.4.1 Validating GC choice

Start by confirming your collector with:

jcmd <pid> VM.flags | grep Use

Correlate GC logs with latency metrics. Frequent full GCs → adjust heap or switch to ZGC. High pause variability → check humongous allocations (G1) or promotion failure (Parallel GC). JFR’s GC pause histogram quickly visualizes this.

7.4.2 Heap sizing in containers

In Kubernetes, rely on percentage-based sizing:

-XX:+UseContainerSupport
-XX:InitialRAMPercentage=50
-XX:MaxRAMPercentage=75

Avoid hardcoded -Xmx unless required. Monitor native and direct buffer memory separately to avoid OOM from off-heap allocations (Netty, ByteBuffer).

7.4.3 Fine-tuning collectors

G1: adjust MaxGCPauseMillis and InitiatingHeapOccupancyPercent.
ZGC: tweak SoftMaxHeapSize for predictable RSS.
Shenandoah: set ShenandoahGCHeuristics=adaptive and adjust concurrent threads.

Validate with 24-hour production JFR recordings. Stability over multiple load phases matters more than synthetic benchmarks.

7.4.4 Case study: Uber-style GC tuning

Uber’s engineering blog detailed tuning G1 for large JVMs. Key takeaways:

Reduce old-gen occupancy threshold to 30–35%.
Avoid large humongous objects; split payloads.
Monitor mixed-collection frequency via GC logs.
Cap pause time to 150 ms, adjusting region size accordingly.

After tuning, Uber saw 30% fewer full GCs and consistent p99 latency under burst load—a realistic outcome for any high-volume microservice.

7.5 Stage 5 – JIT-aware refactoring

7.5.1 Refactoring for inlining and devirtualization

Help the JIT by reducing polymorphism. Convert deep interface hierarchies into sealed classes or records:

sealed interface Payment permits CardPayment, WalletPayment {}
record CardPayment(String id, BigDecimal amt) implements Payment {}

These constructs make call sites monomorphic, enabling inlining. Inlining increases register reuse and removes virtual call overhead.

7.5.2 Reducing megamorphic call sites and reflection

Frameworks heavy in reflection (ORMs, serializers) create megamorphic call sites. Replace reflection with MethodHandles or generated code.

MethodHandle getter = lookup.findGetter(MyClass.class, "value", int.class);
int val = (int) getter.invoke(obj);

This approach lets the JIT optimize calls dynamically. Also cache reflection results; don’t recompute per invocation.

7.5.3 Verifying impact

After refactoring, validate improvement through JITWatch inlining reports and JFR’s compilation statistics. Compare steady-state throughput using JMH. If hot methods remain unoptimized, adjust thresholds with -XX:CompileThreshold.

7.6 Stage 6 – Scaling & cost optimization

7.6.1 Horizontal vs vertical scaling

Vertical scaling (larger JVMs) improves single-instance performance but increases GC complexity. Horizontal scaling (more pods) improves fault tolerance but adds coordination cost.

Benchmark both. For CPU-bound workloads, vertical scaling with ZGC often yields higher efficiency. For IO-heavy APIs, horizontal scaling wins due to better connection distribution.

7.6.2 Rate limits and backpressure

Introduce backpressure early to prevent cascading failures. Use libraries like Resilience4j or Netflix concurrency-limits to bound concurrency:

import resilience4j
# pseudo example
rate_limiter = resilience4j.RateLimiter(limit_for_period=100, refresh_period=1)

In reactive systems, Project Reactor’s onBackpressureBuffer() prevents queue blowups during spikes.

7.6.3 Cost-per-request analysis

Once performance is stable, compute cost per request:

(cost of instance × CPU utilization + memory overhead) / requests per second

For example, switching from G1 to ZGC might increase CPU by 5% but reduce timeouts by 50%, lowering cost per successful request. Tie optimization to ROI rather than raw metrics.

7.7 Stage 7 – Hardening & institutionalizing knowledge

7.7.1 Performance regression tests in CI

Automate benchmarks as part of CI/CD:

mvn verify -Pperformance

Run JMH for microbenchmarks and Gatling or k6 for load tests. Compare GC logs automatically with tools like GCViewer or custom diff scripts to detect regressions.

7.7.2 Golden dashboards and baselines

Create a shared Grafana dashboard with canonical JVM metrics: GC time %, allocation rate, safepoint time, CPU utilization, and latency. Define “golden baselines” for typical services so teams detect anomalies without rediscovering thresholds.

7.7.3 Documentation and post-mortems

Every tuning session should end with a short document:

Baseline metrics before change.
Changes applied (flags, code, config).
Validation results.
Rollback plan.

Keep these in version control alongside code. Over time, you’ll accumulate an internal performance knowledge base—your organization’s own JVM playbook.

8 Checklists, Recipes & Further Reading

While the playbook defines process, teams need quick references. These checklists and templates help standardize JVM performance hygiene across environments. They summarize best practices without requiring deep GC or JIT expertise.

8.1 Quick-start checklists

8.1.1 GC selection cheat sheet

Workload	Recommended GC	Notes
API / microservice (<8 GB)	G1	Balanced latency & throughput
Low-latency trading	ZGC	<10 ms pauses even at 100 GB heaps
Data pipeline / ETL	Parallel GC or G1	Max throughput
Long-lived analytics	Shenandoah	Predictable pauses, big heaps

8.1.2 Container startup template

-XX:+UseContainerSupport
-XX:InitialRAMPercentage=50
-XX:MaxRAMPercentage=75
-XX:+HeapDumpOnOutOfMemoryError
-XX:+ExitOnOutOfMemoryError

Add GC based on service type, e.g., -XX:+UseZGC for latency-sensitive APIs.

8.1.3 JFR recording profiles

Profile	Overhead	Use
default	<0.5%	Continuous production monitoring
profile	~1%	Short-term deep profiling
custom	variable	Targeted investigations

8.2 Copy-pastable tuning recipes

8.2.1 JVM argument sets

Latency-sensitive REST API:

-XX:+UseZGC -XX:SoftMaxHeapSize=2g -Xms1g -Xmx2g
-XX:+AlwaysPreTouch

Batch processor:

-XX:+UseParallelGC -Xms4g -Xmx4g -XX:+UseNUMA

Streaming analytics:

-XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive

8.2.2 Kubernetes resource + JVM settings

resources:
  limits:
    memory: "2Gi"
    cpu: "1"
  requests:
    memory: "1Gi"
    cpu: "0.5"
env:
  - name: JAVA_TOOL_OPTIONS
    value: "-XX:+UseContainerSupport -XX:MaxRAMPercentage=75"

8.2.3 Example JFR configurations

jcmd <pid> JFR.start name=prod settings=default duration=1h filename=prod.jfr

Open in JMC, filter CPU > Allocation > GC views, and save findings in version control for repeat analysis.

8.3 Library & tool starter pack

8.3.1 JVM-level tools

JFR, JMC, async-profiler, JITWatch, JOL.

8.3.2 Application-level stack

Spring Boot Actuator, Micrometer, Prometheus, Grafana, OpenTelemetry SDK.

8.3.3 Testing & benchmarking

JMH for microbenchmarks, Gatling/k6/JMeter for load testing, Testcontainers for realistic environments.

8.4 Recommended further reading

8.4.1 Official documentation

OpenJDK GC tuning guides for G1, ZGC, Shenandoah.
JFR and JMC official user manuals.

8.4.2 Recent articles and talks

“Taming GC in Microservices” (InfoQ, 2024).
“ZGC in Production at LinkedIn.”
“Async Profiler: Modern Java Profiling” (JetBrains).

8.4.3 GraalVM and Native Image optimization guides

GraalVM Native Image Reference Manual.
Spring Boot 3 AOT and Native Build Tools documentation.