Java JVM Internals Cheat Sheet
Explains JVM memory regions, class loading, garbage collectors, GC tuning flags, and diagnostic tools for troubleshooting Java applications.
3 PagesAdvancedApr 12, 2026
JVM Runtime Memory Areas
The regions the JVM divides memory into at runtime.
- Heap- Stores all objects and arrays; shared across threads; divided into Young (Eden, S0, S1) and Old generations.
- Metaspace- Stores class metadata; replaced PermGen in Java 8+; grows into native memory, not the heap.
- Stack- Per-thread; stores stack frames with local variables, operand stack, and return addresses.
- PC Register- Per-thread; holds the address of the current executing JVM instruction.
- Native Method Stack- Per-thread; used for native (JNI) method calls.
- Runtime Constant Pool- Per-class pool (part of Metaspace) holding literals and symbolic references resolved at runtime.
Class Loading & Class Loaders
Delegation model used to load classes.
java
// Class loader hierarchy (parent-first delegation)// Bootstrap ClassLoader -> loads java.lang.*, core JDK classes (native code)// Platform ClassLoader -> loads JDK extension modules (was Ext ClassLoader pre-9)// Application ClassLoader -> loads classes on the classpath// Inspect a class's loaderSystem.out.println(String.class.getClassLoader()); // null (bootstrap)System.out.println(MyApp.class.getClassLoader()); // AppClassLoader// Class loading phases: Loading -> Linking (Verify, Prepare, Resolve) -> Initialization
Common GC & Memory Flags
JVM flags for tuning heap size and garbage collector.
bash
java -Xms512m -Xmx2g -jar app.jar # Initial / max heap sizejava -XX:+UseG1GC -jar app.jar # Use G1 collector (default since JDK 9)java -XX:+UseZGC -jar app.jar # Use low-latency ZGC (JDK 15+)java -XX:MaxMetaspaceSize=256m -jar app.jar # Cap Metaspace sizejava -Xss512k -jar app.jar # Thread stack sizejava -XX:+HeapDumpOnOutOfMemoryError -jar app.jar # Dump heap on OOMjava -Xlog:gc* -jar app.jar # Unified GC logging (JDK 9+)
Garbage Collectors
Built-in collectors and where they fit.
- Serial GC- Single-threaded, stop-the-world; best for small heaps and single-CPU environments (-XX:+UseSerialGC).
- Parallel GC- Multi-threaded throughput collector; stop-the-world for both minor and major GC (-XX:+UseParallelGC).
- G1 (Garbage First)- Region-based, default collector since JDK 9; balances throughput and pause time (-XX:+UseG1GC).
- ZGC- Low-latency, concurrent collector scalable to huge heaps with sub-millisecond pauses (JDK 15+ production).
- Shenandoah- Concurrent, low-pause collector with goals similar to ZGC, developed by Red Hat.
Diagnostic Tools
Command-line tools shipped with the JDK for inspecting a running JVM.
bash
jps # List running JVM processesjstat -gc <pid> 1000 # GC stats every secondjmap -heap <pid> # Heap summaryjmap -dump:file=heap.hprof,live <pid> # Heap dumpjstack <pid> # Thread dumpjcmd <pid> VM.flags # Show active JVM flagsjconsole # GUI monitoring console
Tiered JIT Compilation
How the JVM escalates hot methods through interpreter, C1, and C2 compilation tiers.
bash
# Tier 0: Interpreter# Tier 1: C1 (client) - no profiling, fast compile# Tier 2: C1 with limited profiling# Tier 3: C1 with full profiling# Tier 4: C2 (server) - aggressive optimization using tier-3 profile datajava -XX:+PrintCompilation -jar app.jar # Log each method as it's compiled, with tierjava -XX:TieredStopAtLevel=1 -jar app.jar # Force C1-only (faster warmup, lower peak throughput)java -XX:-TieredCompilation -jar app.jar # Disable tiering, go straight to C2java -XX:CompileThreshold=10000 -jar app.jar # Invocations before C2 compiles (non-tiered)java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -jar app.jar # Show inlining decisions
Disassembling Bytecode with javap
Inspect compiled class files at the bytecode level to understand what javac emitted.
bash
javac Calculator.javajavap -c Calculator.class # Disassemble to JVM bytecode instructionsjavap -v Calculator.class # Verbose: constant pool, stack/locals, line numbersjavap -p Calculator.class # Include private members# Example output fragment for `return a + b;`# 0: iload_1# 1: iload_2# 2: iadd# 3: ireturn# Dump the constant pool to see interned string/class/method referencesjavap -v -p Calculator.class | grep -A5 'Constant pool'
Java Memory Model (JMM) Guarantees
Cross-thread visibility and ordering rules defined by JLS Chapter 17.
- happens-before- Partial order guaranteeing that writes before a synchronization point are visible after it on another thread (e.g. unlock happens-before subsequent lock).
- volatile- Reads/writes are never reordered relative to other volatile accesses and are immediately visible to all threads; does not make compound operations atomic.
- final field freeze- A correctly constructed object's final fields are guaranteed visible to any thread that sees the reference, without extra synchronization.
- Thread.start()/join()- start() happens-before any action in the started thread; all actions in a thread happen-before another thread successfully returns from join() on it.
- instruction reordering- Compiler, JIT, and CPU may reorder independent statements absent synchronization; this is what causes classic double-checked-locking bugs without volatile.
- safe publication- Publishing an object reference via a volatile field, static initializer, final field, or a lock ensures other threads see a fully-constructed object.
Java Flight Recorder (JFR)
Low-overhead, always-available profiler bundled with the JDK for production diagnostics.
bash
# Start recording from launchjava -XX:StartFlightRecording=duration=60s,filename=recording.jfr -jar app.jar# Attach to a running process by PIDjcmd <pid> JFR.start duration=60s filename=recording.jfrjcmd <pid> JFR.check # List active recordingsjcmd <pid> JFR.dump name=1 filename=dump.jfr # Dump without stoppingjcmd <pid> JFR.stop name=1# Continuous low-overhead profile (default.jfc) vs deeper profile.jfcjava -XX:StartFlightRecording=settings=profile -jar app.jar# Open recording.jfr in JDK Mission Control (jmc) for flame graphs, GC pauses, alloc hotspots
Compressed Oops & TLAB Allocation
Pointer compression and thread-local allocation buffers that affect heap footprint and allocation throughput.
bash
# Compressed Oops (default 'on' for heaps < ~32GB): 32-bit object references# instead of 64-bit, shrinking object headers/pointers and improving cache density.java -XX:+UseCompressedOops -jar app.jar # Explicit enable (auto below ~32g heap)java -XX:+PrintCompressedOopsMode -jar app.jar # Show the encoding mode chosen# TLAB: each thread gets a private slice of Eden to bump-allocate into lock-free;# avoids CAS contention on every `new`.java -XX:+UseTLAB -jar app.jar # Enabled by defaultjava -XX:TLABSize=256k -jar app.jar # Initial TLAB size hintjava -XX:+PrintTLAB -jar app.jar # Diagnostic: TLAB stats (older flag, use JFR on newer JDKs)java -Xlog:gc+tlab=trace -jar app.jar # Unified logging equivalent
Pro Tip
Stop-the-world pauses come from GC roots being scanned while all app threads are frozen - favor G1 or ZGC over Parallel GC for latency-sensitive services, but benchmark; Parallel GC often has better raw throughput for batch jobs.
Was this cheat sheet helpful?
Explore Topics
#JavaJVMInternals#JavaJVMInternalsCheatSheet#Programming#Advanced#JVM#Runtime#Memory#Areas#OOP#CheatSheet#SkillVeris
