JVM Tuning & Troubleshooting

Heap is shared objects, Stack is per-thread locals, Metaspace is class blueprints, Code Cache is compiled native code.

New objects live in the Young Gen and mostly die fast; the rare survivors are promoted to the Old Gen, which is why young GC is quick and frequent while full GC is slow and rare.

Minor GC cleans the small Young Gen quickly and often; Major/Full GC cleans the Old Gen or whole heap slowly and rarely, with a longer pause.

Serial for tiny apps, Parallel for throughput, G1 for balanced low pauses (the modern default), ZGC and Shenandoah for ultra-low pauses on huge heaps.

G1 chops the heap into regions, marks garbage concurrently, and collects the fullest-of-garbage regions first to hit a pause-time target.

Pick G1 as the balanced default for most services; pick ZGC when pauses must stay in single-digit milliseconds no matter how big the heap, like trading systems.

`-Xms`/`-Xmx` size the heap, `-XX:+UseG1GC` picks the collector, `-XX:MaxGCPauseMillis` targets pause time, and the Metaspace flags bound class metadata.

A leak is useless objects still referenced; you spot it by ever-rising heap and ineffective Full GCs, then confirm it with a heap dump analyzed in Eclipse MAT.

The JVM interprets first for fast startup, then JIT-compiles hot methods to native code – C1 for quick wins, C2 for peak optimization.

Profile with data, not hunches – JFR records cheaply in production, JMC analyzes it, VisualVM inspects live, and async-profiler gives CPU and allocation flame graphs.

Read the OOM message first to learn which region ran out, then take a heap dump and find what is retaining the memory.

Find the hottest threads with top, take a jstack dump, match the hot native thread IDs to Java stacks, and rule out excessive GC via the GC logs.

A deadlock is threads holding each other's locks forever; find it in a thread dump's BLOCKED threads and fix it with consistent lock ordering or tryLock with a timeout.

Starvation is threads that never get their turn because others hog the CPU or locks, or the pool is too small; a thread dump full of WAITING/BLOCKED threads reveals it.

JMH is the correct way to benchmark JVM code because it handles warm-up, forking, GC, and dead-code elimination that a naive nanoTime loop gets catastrophically wrong.