LESSON 08 · BEGINNER4 min read

JDK Flight Recorder, JFR Events, and Production Memory Profiling

Diagnose production heap churn, thread allocation bottlenecks, and off-heap leaks using JDK Flight Recorder (JFR) and mission control diagnostics.

OpenJDK 21+ (LTS)Free to readModule 2 of 15

YOUR NEXT SMALL WINS

By the end, you’ll be able to…

Profile JVM memory allocations continuously with near-zero overhead using JDK Flight Recorder
Identify memory leak candidates by analyzing survivor space occupancy and promotion rates
Inspect off-heap native memory tracking (NMT) to detect direct buffer and metaspace expansion

01The Architecture of Continuous Profiling with JFR

Traditional JVM profiling tools such as JVMTI agents introduce significant runtime overhead—often slowing execution throughput down by 15% to 50% through bytecode instrumentation and safepoint polling. In high-throughput production environments processing financial transactions or distributed RPC calls, invasive instrumentation creates an observer effect where timing anomalies and race conditions vanish or mutate.

JDK Flight Recorder (JFR) solves this fundamental observability problem by embedding event emission hooks directly into the HotSpot C++ runtime, assembly stubs, and GC execution phases. Because JFR writes structured circular binary buffers into thread-local ring buffers before flushing them to operating system disk pages asynchronously, its performance penalty is typically under 1%. This allows engineering teams to leave JFR enabled continuously in 24/7 mission-critical deployments.

When diagnosing memory pressure, JFR captures detailed allocation events categorized into inside TLAB (Thread-Local Allocation Buffer) and outside TLAB. Objects allocated outside TLABs immediately reveal high-volume single allocations that bypass generational nurseries, causing premature GC cycles.

example.js☕Java

Ctrl + ↵

import jdk.jfr.Configuration;
import jdk.jfr.Recording;
import java.nio.file.Path;

public class JfrProfilingDemo {
    public static void main(String[] args) throws Exception {
        Configuration config = Configuration.getConfiguration("profile");
        try (Recording recording = new Recording(config)) {
            recording.start();
            System.out.println("Continuous JFR recording initiated under profile preset...");
            
            // Simulate workload triggering allocations
            allocateWorkload();
            
            recording.stop();
            Path dumpPath = Path.of("production-heap-profile.jfr");
            recording.dump(dumpPath);
            System.out.println("Flight recording successfully written to: " + dumpPath.toAbsolutePath());
        }
    }

private static void allocateWorkload() {
        for (int i = 0; i < 100_000; i++) {
            byte[] buffer = new byte[1024]; // 1 KB chunks
            if (i % 20_000 == 0) {
                System.out.printf("Processed %d memory allocation cycles%n", i);
            }
        }
    }
}

Output

Click Run or press Ctrl+Enter

Output will appear here after you run the code.

02Native Memory Tracking (NMT) and Off-Heap Leaks

A common pitfall in production Java services is assuming that heap memory accounts for total process resident set size (RSS). When an application's heap is capped at 4GB via -Xmx4g, operating system monitoring agents may nevertheless report 7GB of consumed physical RAM before the Linux Out-Of-Memory (OOM) killer terminates the JVM process.

This divergence arises from off-heap consumers: Metaspace holding class metadata, thread stacks allocating default 1MB stack buffers per OS thread, JIT compilation code caches, DirectByteBuffer allocations used by high-performance NIO servers like Netty, and native C++ libraries loaded via JNI or the Foreign Function & Memory (FFM) API.

To systematically identify the root cause of off-heap expansion, engineers enable HotSpot Native Memory Tracking using -XX:NativeMemoryTracking=detail. By establishing baseline snapshots with jcmd <pid> VM.native_memory baseline and comparing subsequent snapshots via VM.native_memory detail.diff, memory leaks in off-heap arenas become immediately visible.

03Memory Allocation Trace Table and Leak Diagnostics

Analyzing heap dumps with tools like Eclipse Memory Analyzer (MAT) or JMC involves calculating retained heap sizes versus shallow heap sizes. The shallow heap is the memory consumed by the object itself (its 12-byte header, 4-byte padding, and reference fields). The retained heap represents the cumulative memory reclaimed if that specific object were garbage collected.

Consider this trace table contrasting heap allocation behaviors across different data structures:

notes.txtPlain text

+-----------------------+------------------+---------------------+-------------------------------+| Data Structure        | Shallow Size (B) | Retained Size (1M)  | Common Failure Mode           |+-----------------------+------------------+---------------------+-------------------------------+| byte[1048576]         | 1,048,592        | 1,048,592           | Humongous allocation in G1    || ArrayList<Integer>    | 24 (empty)       | ~24 MB (boxed ints) | Boxed object pointer bloat    || ConcurrentHashMap     | 64 (empty)       | High internal table | Unbounded cache without TTL   || ThreadLocal<Context>  | 32               | Leaked ThreadLocal  | ThreadPool retains stale refs |+-----------------------+------------------+---------------------+-------------------------------+

04Production Best Practices for Memory Reliability

To safeguard production microservices against silent memory degradation, adhere to these battle-tested operational rules: First, always configure -XX:+HeapDumpOnOutOfMemoryError and specify -XX:HeapDumpPath to persist automated post-mortem state for offline diagnosis.

Second, replace unbounded caches with size-bounded, time-evicting caches (such as Caffeine Cache), ensuring that weak keys or soft values are selected only when specifically suited for transient caching scenarios.

Third, when building concurrent servers that make heavy use of virtual threads or worker pools, avoid storing heavy mutable domain objects in ThreadLocal storage, as thread pooling causes object references to outlive the logical request lifecycle.

LET IT CLICK

The ideas worth keeping.

JDK Flight Recorder allows 24/7 continuous production profiling with sub-1% performance overhead.
Native Memory Tracking (NMT) bridges the visibility gap between JVM heap caps and operating system process RSS.
Always clean ThreadLocal storage in a finally block to avoid thread-pool memory leaks.

TURN UNDERSTANDING INTO SOMETHING YOU CAN DO

Make it yours.

Type and test your code right here in the interactive workspace. Run your solution, check the output, and compare with the worked guide when ready.

Exercise 1: Configure a Java command line snippet and dia

Configure a Java command line snippet and diagnostic strategy to track native off-heap memory growth and capture a heap dump automatically when an OutOfMemoryError occurs.

your_turn_1.java☕Java

Ctrl + ↵

Output

Click Run or press Ctrl+Enter

Output will appear here after you run the code.

Explore a worked solution

one_possible_solution.javaJava

// JVM Flags:// -XX:NativeMemoryTracking=detail -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/dumps/oom.hprof// Diagnostic Commands:// 1. Establish baseline after application warm-up://    jcmd <pid> VM.native_memory baseline// 2. Measure memory drift under load://    jcmd <pid> VM.native_memory detail.diff

Remember to combine -XX:NativeMemoryTracking with the jcmd utility for differential off-heap profiling.

Exercise 2: Explain why storing large objects in ThreadLo

Explain why storing large objects in ThreadLocal can cause insidious memory leaks in a server using thread pooling, and how to safely clean it up.

your_turn_2.java☕Java

Ctrl + ↵

Output

Click Run or press Ctrl+Enter

Output will appear here after you run the code.

Explore a worked solution

one_possible_solution.javaJava

public class SecurityContextHolder {    private static final ThreadLocal<byte[]> USER_TOKEN = new ThreadLocal<>();    public static void setToken(byte[] token) {        USER_TOKEN.set(token);    }    public static byte[] getToken() {        return USER_TOKEN.get();    }    public static void clear() {        // Essential: must be called in a finally block to prevent        // pooled worker threads from retaining references indefinitely        USER_TOKEN.remove();    }}

ThreadLocal.remove() must always be called inside a finally block when worker threads are reused.

Keep exploring.

The official references behind this lesson, when you want a second angle or the full details.

MODULE 02 · PRACTICAL SELF-CHECK

Pause. Put the pieces together.

You’ve reached the end of JVM Memory Layout, Stack vs Heap & Garbage Collectors. Before moving on, use this task to check what you can do independently.

Analyze a heap dump and diagnose off-heap memory growth using Native Memory Tracking.

Try it in your own environment and write down the result. This is a self-check; reading completion does not evaluate your code.

Review this module

One lesson closer.

Reading is a start. Trying it yourself makes the connection.

Solve the hands-on coding challenge in the knowledge section to verify your code and unlock lesson completion.

By the end, you’ll be able to…

01The Architecture of Continuous Profiling with JFR

02Native Memory Tracking (NMT) and Off-Heap Leaks

03Memory Allocation Trace Table and Leak Diagnostics

04Production Best Practices for Memory Reliability

The ideas worth keeping.

Make it yours.

Exercise 1: Configure a Java command line snippet and dia

Exercise 2: Explain why storing large objects in ThreadLo

What stayed with you?

Exercise 1: Configure a Java command line snippet and dia

Keep exploring.

Pause. Put the pieces together.

One lesson closer.