JVM Tuning, GC Logs & Memory Footprint — Interview Questions

How to use this lesson

Senior tuning answers follow one discipline:

1. Measure (GC logs, JFR, metrics).
2. Form a hypothesis.
3. Change one thing.
4. Verify under realistic load.

Most "tuning" is removing bad flags, sizing the heap correctly for the container, and allocating less. Say that, and you'll stand out.

Q1. What's the effect of -Xms and -Xmx, and what are the best practices?

Short answer: -Xms sets the initial heap and -Xmx the maximum. The heap grows and shrinks between them. Best practices:

• Services: set -Xms equal to -Xmx, to avoid resize pauses and surprise growth, and add -XX:+AlwaysPreTouch to fault pages in at startup, so latency is consistent.
• Containers: prefer -XX:MaxRAMPercentage=70–75 (and InitialRAMPercentage) over hard-coded sizes, leaving 25–30% for non-heap memory (Metaspace, threads, code cache, direct buffers). Otherwise the pod is OOMKilled despite a "healthy" heap.
• Size from the live set: after a full or old collection, the old generation's occupancy is your live data. Heap ≈ 3–4× the live set for G1 is a good starting point.
• Stay below about 31 GB to keep compressed oops, or jump well above it.
• Too small means frequent GCs and OOMs. Too large means longer pauses with non-concurrent collectors, and wasted memory.

Q2. What does -XX:+PrintGCDetails show, and how do you read GC logs?

Short answer: -XX:+PrintGCDetails printed per-collection details: the generation sizes before and after, the pause time, and the cause. Since Java 9 it's deprecated, and mapped onto unified logging. Use:

-Xlog:gc*,gc+phases=debug,safepoint:file=/var/log/app/gc-%p-%t.log:time,uptime,level,tags:filecount=10,filesize=50m

A G1 line looks like:

[2026-09-25T10:15:02.114+0000][123.456s][info][gc] GC(512) Pause Young (Normal) (G1 Evacuation Pause) 3480M->1210M(4096M) 18.734ms

It shows the collection number, type (young, mixed, full, remark, cleanup), cause, heap before → after (committed), and the pause duration.

What to look at:

• pause times against the SLO (p99, max);
• frequency;
• heap after GC trending upwards (a leak);
• Full GCs and their reasons;
• to-space exhausted;
• humongous allocations;
• GC CPU overhead (the percentage of time in GC).

Tools: GCeasy, GCViewer, JDK Mission Control, or Grafana dashboards from jvm_gc_* metrics.

Q3. How do you analyse a GC log to detect memory pressure?

Short answer: These signs indicate pressure:

• High GC frequency, with little reclaimed per collection (after-GC occupancy close to before-GC).
• After-GC old-generation occupancy that's high (> 70–80% of the old generation), and rising.
• GC time above about 5–10% of wall-clock time (throughput loss). Parallel GC's GC overhead limit exceeded triggers at 98% time spent in GC, with less than 2% recovered.
• Promotion rate too high, or premature promotion (tenuring thresholds dropping to 1).
• G1 mixed collections that can't keep up, to-space exhausted, Full GC (Allocation Failure).
• ZGC Allocation Stall entries.

Plot the "heap after GC" floor over time. Rising means a leak or a growing live set. Flat but high means the heap is too small for the live set.

Q4. What does -XX:+UseG1GC do, and which G1 parameters are worth tuning?

Short answer: It selects G1, the default on server-class machines since Java 9, so it's usually only needed to override Serial in small containers. Tune as little as possible:

• -XX:MaxGCPauseMillis (default 200): the pause goal. G1 adapts the young-generation size to meet it.
• -XX:G1HeapRegionSize (1–32 MB, and up to 512 MB in newer releases): raise it to avoid humongous objects if you allocate large arrays.
• -XX:InitiatingHeapOccupancyPercent (with adaptive IHOP on by default), and -XX:G1ReservePercent: start concurrent marking earlier to prevent evacuation failures.
• -XX:ParallelGCThreads/ConcGCThreads: in CPU-constrained containers.
• -XX:G1NewSizePercent/G1MaxNewSizePercent: bound the young generation (they're experimental flags, so avoid them unless measured).

Common trap: setting -Xmn or NewRatio with G1. A fixed young size disables G1's pause-time adaptation.

Q5. How do -XX:SurvivorRatio and -XX:MaxTenuringThreshold affect GC behaviour?

Short answer:

• SurvivorRatio is the Eden-to-one-Survivor ratio (8 means Eden is 8/10 of the young generation, and each survivor space 1/10). Survivors too small means live objects overflow into the old generation early: premature promotion, which fills the old generation and causes more old or full GCs.
• MaxTenuringThreshold (default 15, the maximum) is the number of young GCs an object must survive before promotion. The JVM computes an adaptive threshold, based on survivor occupancy (TargetSurvivorRatio).
  • Lower means short/medium-lived objects get promoted, which bloats the old generation.
  • Higher means more copying in the young generation, but less old-generation pressure.

Check -Xlog:gc+age=trace to see the age distribution. This matters most for Parallel or Serial. With G1, prefer leaving the young generation adaptive.

Q6. What is heap fragmentation, and how do you avoid it?

Short answer: Fragmentation happens when free memory is scattered in small holes, so a large allocation fails even though total free space is enough. That triggers Full GCs, or an OOM. It happens with non-compacting collectors (CMS's old generation), and in G1 with humongous objects (they need contiguous free regions).

Avoid it by:

• using compacting collectors (G1, ZGC, Shenandoah, Parallel);
• avoiding very large, short-lived arrays (stream or chunk the data, reuse buffers);
• increasing the G1 region size so big objects aren't humongous;
• keeping heap headroom.

Off-heap fragmentation (the native malloc arenas) can also grow RSS. Consider MALLOC_ARENA_MAX, or jemalloc, for native-heavy applications.

Q7. What tuning options are there for ZGC and Shenandoah?

Short answer: Both are designed to need very little tuning:

• ZGC:
  • -XX:+UseZGC (generational by default since 23; -XX:+ZGenerational is no longer needed, and the non-generational mode was removed in 24).
  • The most important knob is heap size (-Xmx): give it headroom so concurrent collection finishes before allocation stalls.
  • Optional: -XX:SoftMaxHeapSize (try to stay below it), -XX:ConcGCThreads, -XX:ZUncommitDelay, and -XX:+UseLargePages (or transparent huge pages set to madvise).
• Shenandoah:
  • -XX:+UseShenandoahGC.
  • The heuristics (-XX:ShenandoahGCHeuristics=adaptive|static|compact|aggressive).
  • Generational mode (-XX:ShenandoahGCMode=generational, a product feature in Java 25).
  • Heap size and GC thread counts.

Watch for allocation stalls or pacing in the logs. They mean the heap or GC threads are insufficient.

Q8. How would you size the young and old generations for a high-throughput application?

Short answer:

1. Measure the live set (the old generation after a full or mixed GC) and the allocation rate (MB/s, from the GC logs or JFR).
2. Old generation: hold the live set plus headroom, usually 1.5–2× the live set, to avoid Full GCs.
3. Young generation: make it large enough that most objects die in it. Size Eden so young GCs run at an acceptable interval: interval ≈ Eden size / allocation rate. Bigger Eden means fewer GCs, and similar pause cost, because copying depends on survivors, not on Eden size.
4. Survivors: big enough to hold the medium-lived objects across a few GCs, without overflowing.
5. Pick the collector: Parallel GC, for pure throughput batch work; G1 with a relaxed pause goal (for example 500 ms) otherwise.
6. Iterate with production-like load, comparing throughput (GC time %) and pauses.

Q9. What are the signs in GC logs that indicate a memory leak?

Short answer:

• The post-GC heap occupancy floor keeps rising over hours or days, and never returns to its baseline, even after full or mixed collections.
• Old-generation collections reclaim less and less.
• Full GCs grow more frequent, and eventually run back to back, followed by OutOfMemoryError.
• For Metaspace leaks: a rising Metaspace size, and Full GC (Metadata GC Threshold) entries.

Confirm with heap-dump diffs (two dumps some time apart) or JFR's Old Object Sample event, which records allocation stack traces of long-lived objects.

Q10. What is Metaspace tuning?

Short answer: Metaspace grows in native memory, unbounded by default. The flags:

• -XX:MaxMetaspaceSize: a cap, so a classloader leak fails fast with OOM: Metaspace, instead of consuming the container's memory.
• -XX:MetaspaceSize: the initial high-water mark. Reaching it triggers a GC to unload classes. Raise it for large applications, to avoid early "Metadata GC Threshold" Full GCs at startup.
• -XX:CompressedClassSpaceSize (default 1 GB): for applications with huge numbers of classes.

Tune from observations (jcmd <pid> VM.metaspace, the NMT class section), and fix classloader leaks rather than just raising limits.

Q11. What is direct memory?

Short answer: Off-heap native memory allocated for ByteBuffer.allocateDirect() (and used internally by NIO for socket and file I/O, by Netty, and by gRPC). The OS can do I/O directly on it, with no copy between the Java heap and native buffers, which makes it good for network servers and large I/O. It's limited by -XX:MaxDirectMemorySize (defaults to roughly -Xmx). When exhausted, you get OutOfMemoryError: Direct buffer memory.

Key points to cover:

• Direct buffers are freed when their small heap wrapper is GC'd, through a Cleaner. A large heap with rare GCs can hold onto lots of direct memory. Pool them (Netty's PooledByteBufAllocator).
• Track them with NMT (Internal/Other), or BufferPoolMXBean.
• The Java 22 FFM API (Arena) gives deterministic off-heap lifetimes.

Q12. What's the impact of JVM flags on performance tuning?

Short answer: Flags control heap and memory sizing, GC choice and behaviour, JIT behaviour, CPU detection and diagnostics. The high-impact, commonly correct ones:

• Memory: -Xms/-Xmx, or -XX:MaxRAMPercentage in containers; -XX:MaxMetaspaceSize; -XX:MaxDirectMemorySize; -Xss (per-thread stack).
• GC: -XX:+UseG1GC/UseZGC/UseParallelGC; -XX:MaxGCPauseMillis.
• CPU: -XX:ActiveProcessorCount=N, when container CPU quotas mislead the ergonomics (it affects GC and JIT thread counts, and the ForkJoin common pool size).
• Diagnostics (always on in production): -Xlog:gc* (not the deprecated PrintGCDetails), -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=..., -XX:+ExitOnOutOfMemoryError (let the orchestrator restart the process cleanly), and continuous JFR (-XX:StartFlightRecording).
• Startup: CDS or AOT cache flags, and -XX:TieredStopAtLevel=1 for tools.

Common trap: copying old flag lists: -XX:+UseConcMarkSweepGC, -XX:+UseParNewGC, -XX:PermSize, -XX:+AggressiveOpts. These are removed or invalid on modern JVMs. Some even prevent startup. Unknown -XX options are fatal.

Q13. How do you optimise JVM garbage collection?

Short answer: In order:

1. Enable GC logging and JFR, and establish baselines: pause p99, GC CPU %, allocation rate, live set.
2. Reduce allocation in hot paths (JFR's allocation profiling or async-profiler -e alloc). This is the biggest win.
3. Size the heap correctly for the live set and the container. Avoid swapping, and CPU throttling.
4. Choose the right collector: G1 by default, ZGC for low latency, Parallel for batch.
5. Fix the specific pathologies: humongous allocations, premature promotion, reference-processing storms, System.gc() calls.
6. Change one flag at a time, and verify under load.

Q14. How do you design a high-performance system with minimal garbage collection?

Short answer: Allocate less, and keep what you do allocate short-lived:

• Primitives and primitive collections (fastutil, Eclipse Collections, Agrona), rather than boxed types.
• Avoid temporary objects in hot loops: streams and lambdas are usually fine, and escape analysis helps, but watch for boxing, varargs and iterator allocation in tight loops.
• Reuse buffers: ThreadLocal or pooled ByteBuffers and StringBuilders. Flyweights for repeated values. Interning of hot immutable keys.
• Off-heap storage for large datasets (Chronicle Map, memory-mapped files, the FFM API) to shrink the live heap.
• Streaming processing, instead of materialising big collections.
• Mechanical sympathy: arrays of primitives, flat data layouts, and ring buffers (LMAX Disruptor) for message passing.
• A low-pause collector (generational ZGC), plus heap headroom.
• Measure with JFR allocation profiling before and after.

Common trap: "use object pooling everywhere". Pooling ordinary short-lived objects is usually slower with modern GCs: young-generation allocation and collection are nearly free, while pools create long-lived objects, synchronisation, and leak risks. Pool only expensive resources (connections, threads, large direct buffers).

Q15. How would you improve the scalability and memory efficiency of a large Java application?

Short answer:

• Memory efficiency:
  • Right-size data structures (initial capacities, ArrayList.trimToSize for long-lived lists).
  • Avoid duplicate strings (G1's -XX:+UseStringDeduplication, or interning domain codes).
  • Compact representations (enums, BitSet, primitive arrays).
  • Enable compressed oops and compact object headers (Java 25 -XX:+UseCompactObjectHeaders).
  • Bounded caches (Caffeine, with size or weight limits).
  • Paginate and stream database results.
• Scalability:
  • Stateless instances that scale horizontally.
  • Virtual threads for I/O-bound concurrency (fewer platform threads means less stack memory).
  • Asynchronous and non-blocking I/O where it's needed.
  • Connection pooling sized to the database.
  • Caching with explicit invalidation.
  • Partitioned work (Kafka partitions).
• Measure everything: heap dumps for footprint (the dominator tree), JFR for allocation, load tests for throughput and latency.

Q16. How do the JRE and JVM help reduce an application's memory footprint?

Short answer: The JVM provides the mechanisms, and you have to enable and design for them:

• GC reclaims unreachable objects. Choosing a collector and heap size sets the footprint versus pause trade-off. G1 and ZGC uncommit unused memory back to the OS.
• Compressed oops, compressed class pointers, and compact object headers shrink every object and reference.
• CDS/AppCDS shares class metadata across JVM processes.
• String deduplication (G1) and compact strings (Java 9: Latin-1 strings use 1 byte per char).
• JIT escape analysis removes allocations.
• A modular runtime: since Java 9 there's no separate JRE download. jlink builds a custom minimal runtime image containing only the modules you use, which means smaller container images and less memory mapped.
• Container awareness: heap ergonomics based on cgroup limits.

For the smallest footprint, GraalVM native images remove the JIT and most of the metadata, at the cost of peak throughput and build complexity.

Follow-up questions this topic invites — and their answers

Q: Why does my container get OOMKilled when the heap is only 60% full? A: The container limit covers the whole process: heap + Metaspace + code cache + thread stacks + direct and mapped memory + GC structures + native libraries. Enable NMT to see the breakdown, lower MaxRAMPercentage, cap Metaspace and direct memory, and reduce thread counts (or use virtual threads).

Q: What does -XX:+ExitOnOutOfMemoryError buy you? A: After an OOM, the JVM's state is unreliable. Exiting immediately (with a heap dump written first) lets Kubernetes restart a clean instance, instead of leaving a zombie that fails requests.

Q: How do you check which flags are actually in effect? A: java -XX:+PrintFlagsFinal -version, jcmd <pid> VM.flags and jcmd <pid> VM.command_line. The JFR recording's JVM information event also lists them.

Q: Is it worth setting -XX:+UseStringDeduplication? A: For heaps with many duplicate strings (parsed JSON, CSV data), yes with G1 (and other collectors that support it). It deduplicates the backing arrays of long-lived strings in the background, at a small CPU cost. Measure the saving in the logs (-Xlog:stringdedup).