Symptoms & Diagnosis
Java 21 introduces revolutionary features like Virtual Threads and Generative ZGC. However, these advancements can lead to unexpected memory overhead if not monitored correctly.
The first sign of a Java 21 memory leak is often “Java 21 Slow Performance.” This manifests as increased latency or frequent Garbage Collection (GC) pauses. You may observe the Resident Set Size (RSS) of your process climbing steadily without plateauing.
| Symptom | Common Root Cause | Diagnostic Tool |
|---|---|---|
| OutOfMemoryError: Java heap space | Unreleased object references in collections. | VisualVM, Eclipse MAT |
| OutOfMemoryError: Metaspace | Dynamic class loading or leak in classloaders. | jstat -gc |
| High CPU with low throughput | GC overhead limit exceeded (ZGC/G1). | jmc (Java Mission Control) |
| Virtual Thread Pinning | ThreadLocal misuse in Virtual Threads. | -XX:+TracePinnedVirtualThreads |
Troubleshooting Guide
To resolve a Java 21 memory leak, you must capture a heap dump during the peak of memory consumption. This allows you to identify which objects are occupying the most space.
Use the jcmd utility to trigger a heap dump without stopping the application. This is more efficient than older methods for modern JDKs.
# Get the process ID (PID)
jps -l
# Generate a heap dump in HPROF format
jcmd <PID> GC.heap_dump /tmp/java_21_leak_dump.hprof
# Check Virtual Thread statistics
jcmd <PID> Thread.dump_to_file -format=json /tmp/threads.jsonAnalyze the dump file using Eclipse Memory Analyzer (MAT). Look for the “Leak Suspects” report. In Java 21, pay close attention to ThreadLocal variables if you are using Virtual Threads, as they do not behave like traditional platform threads and can retain large objects longer than expected.
Addressing Generative ZGC Issues
If you are using the new Generative ZGC in Java 21, ensure your heap size is appropriately tuned. Sometimes “leaks” are actually just the collector not being aggressive enough under high allocation rates.
# Enable Generative ZGC logging to find allocation stalls
java -XX:+UseZGC -XX:+ZGenerative -Xlog:gc*:file=gc.log -jar app.jarPrevention
The best way to fix a memory leak is to prevent it through architectural best practices. In Java 21, this specifically involves the lifecycle management of concurrent resources.
Switch from ThreadLocal to ScopedValues where possible. Scoped values are designed for the massive scale of Virtual Threads and automatically clear data once the scope is closed, preventing accidental retention.
Always use try-with-resources for streams and network connections. Even with Java 21’s improved GC, unclosed native resources can cause the “slow performance” symptoms often mistaken for heap leaks.
Finally, set realistic memory limits. Use -Xmx and -Xms flags to provide the JVM with a stable boundary. This ensures the Garbage Collector can operate within its optimal threshold before the OS kills the process.