Memory Leaks, OutOfMemoryErrors & Profiling Tools — Interview Questions

How to use this lesson

Interviewers want a runbook, not a list of tools:

1. Which signal told you something was wrong?
2. Which artefact did you capture (a heap dump, a JFR recording, thread dumps)?
3. How did you read it, and what did you change?
4. How did you prove the fix?

Answer with a real incident if you can.

Q1. What is a memory leak in Java, and how does it differ from C/C++?

Short answer:

• In C/C++, a leak is memory that was allocated and never freed. Once the pointer is lost, it's unreachable forever.
• Java's GC frees everything unreachable, so a Java leak is the opposite: objects that are still reachable (through a static collection, a listener, a cache, a ThreadLocal, or a class loader) but no longer needed. The GC can't know you won't use them again. Memory grows until performance degrades (GC thrashing), and finally an OutOfMemoryError.

Key points to cover:

• Java also has native leaks: direct buffers, JNI or JNA allocations, unclosed native resources (zip inflaters, some image libraries), and thread stacks from unbounded thread creation. They show up in RSS and NMT, not in heap dumps.

Learn it in depth → Memory Leaks in Java

Q2. How can static references cause memory leaks?

Short answer: Static fields live as long as their class (and its class loader), which for application classes means forever. Everything reachable from a static field is pinned:

• static Map/List caches without eviction, which is the #1 leak;
• static listener or observer registries where listeners are never removed;
• singletons holding request-scoped objects (users, sessions, large results);
• static references to class loaders or Class objects from other modules, which pins entire applications (redeploy leaks);
• static ThreadLocals whose values are never remove()d in pooled threads.

Fix: bounded caches with eviction (Caffeine), explicit unregistration, lifecycle hooks (@PreDestroy), weak-keyed maps where the semantics allow, and ThreadLocal.remove() in finally.

Q3. Your application leaks memory through badly handled cache objects. How would you "optimise memory management using L1 and L2 garbage collection"?

Short answer: There's no L1/L2 garbage collection in the JVM. The question is really about a two-level cache, plus bounded memory:

• L1: a local in-process cache (Caffeine). Size- or weight-bounded, with TTL/TTI expiry and W-TinyLFU eviction. It's small, fast, and per instance.
• L2: a distributed cache (Redis). It's shared across instances, holds larger datasets with TTLs, and keeps the bulk of the data off the JVM heap.
• The leak fix itself:
  • Replace unbounded HashMap caches with bounded ones.
  • Never key caches by objects with broken equals/hashCode, or mutable keys.
  • Avoid caching huge objects. Cache IDs or compact DTOs.
  • Add eviction on updates.
  • Monitor cache size, hit ratio and evictions.
• About soft and weak references: SoftReference caches let the GC evict entries under memory pressure. They're not a good primary policy: eviction is unpredictable, and there's GC churn under pressure. WeakHashMap suits metadata keyed by objects whose lifetime is managed elsewhere, not general caching.

Cache<String, ProductDto> l1 = Caffeine.newBuilder()
        .maximumSize(50_000)
        .expireAfterWrite(Duration.ofMinutes(5))
        .recordStats()
        .build();

ProductDto get(String sku) {
    return l1.get(sku, k -> redis.get(k)                  // L2
            .orElseGet(() -> loadAndStoreInRedis(k)));    // source of truth
}

Common trap: repeating "L1 and L2 garbage collection" as if they were JVM features.

Q4. How do you detect and debug a memory leak in production?

Short answer:

1. Detect it: dashboards on heap used after GC (the old-generation floor), GC time %, and RSS, with alerts on a sustained upward trend, not on raw usage.
2. Capture evidence safely:
   • -XX:+HeapDumpOnOutOfMemoryError (always on, with enough disk).
   • An on-demand dump: jcmd <pid> GC.heap_dump /dumps/app.hprof. It pauses the JVM, and the file is about the size of the heap, so take it from an instance drained from the load balancer if you can.
   • JFR with Old Object Sample (jdk.OldObjectSample), a low-overhead way to find what's living long, with allocation stack traces.
   • A class histogram (jcmd <pid> GC.class_histogram) taken over time, to see which types grow.
3. Analyse in Eclipse MAT: Leak Suspects, the dominator tree (the biggest retained sizes), then Path to GC Roots (excluding weak/soft references), to find the field, collection, thread or class loader holding the objects.
4. Compare two dumps, hours apart, to see which object counts keep growing.
5. Fix, then verify: the post-GC floor stays flat under a soak test.

Learn it in depth → GC Tuning & Diagnostics

Q5. How do you handle Java heap dumps?

Short answer:

• Capture them:
  • automatically on OOM (-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps);
  • on demand with jcmd <pid> GC.heap_dump (the live option forces a Full GC first);
  • in Kubernetes, write to a mounted volume, or kubectl cp it out.
• Treat them as sensitive data. They contain passwords, tokens and personal data that were in memory. Restrict access, encrypt them, and set retention rules.
• Analyse them: use Eclipse MAT (headless ParseHeapDump.sh for huge dumps on a big-memory machine), VisualVM, or IntelliJ's profiler.
• Plan for size and pause: dumping a 30 GB heap takes time and disk. Drain traffic first, and consider -XX:HeapDumpGzipLevel (Java 17+) to compress it.

Q6. How can you use VisualVM to identify a memory leak?

Short answer:

1. Attach VisualVM to the JVM: locally, or through JMX, or an SSH tunnel.
2. In Monitor, watch the heap graph. A saw-tooth pattern whose troughs keep rising after GCs suggests a leak.
3. Use the Sampler → Memory view to see which classes' instance counts or bytes grow over time, and take snapshots to compare.
4. Heap Dump, then browse the classes with the most retained size, and the references to GC roots (for deep analysis, open the dump in MAT).

It's great for development and QA. For production, prefer JFR (low overhead, always-on) and offline dump analysis.

Q7. How does JConsole help monitor thread deadlocks and memory usage?

Short answer: JConsole is a JMX client bundled with the JDK:

• The Memory tab shows heap and non-heap pools (Eden, Old, Metaspace) over time, and a "Perform GC" button.
• The Threads tab shows thread counts, states and stack traces, and a "Detect Deadlock" button, which uses ThreadMXBean.findDeadlockedThreads() to find cycles of threads waiting on monitors or ownable synchronisers.
• The MBeans tab browses and invokes application MBeans (for example, changing log levels).

It's basic but universal. Modern setups export the same MXBeans to Prometheus through Micrometer, and alert on them.

Q8. What is Java Flight Recorder (JFR), and how does it differ from VisualVM? What are JFR and JMC?

Short answer:

• JFR is an event recorder built into the JVM (free since Java 11). It captures GC, allocations (sampled), locks, I/O, exceptions, CPU samples, JIT activity, safepoints, and custom application events, into a binary ring buffer, with about 1–2% overhead. So it can run continuously in production (-XX:StartFlightRecording=disk=true,maxage=6h,settings=profile), and be dumped on demand (jcmd <pid> JFR.dump).
• JMC (JDK Mission Control) is the desktop tool for analysing JFR recordings: automated analysis rules, hot methods, allocation pressure, lock contention, GC phases and memory-leak (Old Object) views.
• VisualVM is an interactive attach-and-watch tool (JMX, a sampler, profiler, heap dumps), better suited to development than to always-on production recording.

Since Java 14 there's JFR event streaming (RecordingStream) for live in-process monitoring. Java 25 adds CPU-time sampling on Linux, and method timing and tracing events.

Q9. How does JMC help with performance tuning?

Short answer: JMC turns a JFR recording into answers:

• the Automated Analysis page flags issues (high GC pressure, lock contention, excessive exceptions, thread stalls);
• Method profiling: hot paths from CPU samples;
• Memory: allocation by class and by stack trace (TLAB and outside-TLAB samples), and GC pauses by phase;
• Lock instances: contended monitors and who blocks whom;
• I/O: slow file and socket operations;
• a timeline correlation of GC pauses against latency spikes.

The workflow is: record under realistic load → find the top allocator or lock → fix → record again and compare.

Q10. What are the pros and cons of sampling versus instrumentation-based profiling?

Short answer:

• Sampling: periodically capture thread stacks (JFR, async-profiler, VisualVM Sampler).
  • Pros: low overhead, safe in production, and no code changes.
  • Cons: statistical, so it can miss short or rare events. Naive samplers suffer safepoint bias, which JFR and async-profiler (which uses AsyncGetCallTrace and perf events) avoid. It gives no exact call counts.
• Instrumentation: inject timing code at method entry and exit (bytecode agents, VisualVM's profiler, APM agents).
  • Pros: exact call counts and timings, and full call trees.
  • Cons: high overhead that distorts results (it inhibits inlining, and short methods appear expensive). Use it only on narrow scopes.

Practice: sample to find the hotspots, then instrument narrowly (or add JFR custom events, or Micrometer timers) to measure specific operations precisely.

Q11. How do you track object allocations and GC pressure with JFR or JMC?

Short answer:

• Record with the profile settings, which include the allocation events:
  • jdk.ObjectAllocationSample (Java 16+), a throttled, low-overhead sample of allocations with stack traces;
  • jdk.ObjectAllocationInNewTLAB/OutsideTLAB, in older setups.
• In JMC's Memory → Allocations view, sort by the allocating stack trace and class, and look for hot allocators in request paths: boxing, String.format, stream pipelines, byte arrays from serialisation.
• Correlate with GC events: allocation rate (MB/s), young GC frequency, and promotion.
• Command-line alternatives: jfr print --events jdk.ObjectAllocationSample rec.jfr, or async-profiler -e alloc, with flame graphs.

Q12. How would you identify a classloader memory leak?

Short answer: The typical symptom is OutOfMemoryError: Metaspace, or growth after redeploys or plugin reloads, with many instances of the same class loader type (WebappClassLoader, RestartClassLoader, plugin loaders).

1. jcmd <pid> VM.classloader_stats or VM.metaspace show many live loaders, and growing class counts.
2. Take a heap dump. In MAT, list the class loader instances, find the ones that should be dead (old application generations), and run Path to GC Roots.
3. The usual culprits:
   • threads started by the application and never stopped (their context class loader or Runnable pins the loader);
   • ThreadLocal values in container threads;
   • JDBC drivers registered in DriverManager;
   • JMX MBeans, shutdown hooks and logging frameworks holding references;
   • static caches in parent-loaded libraries holding application classes.
4. Fix by cleaning up on undeploy: stop the threads, deregister the drivers and MBeans, and call ThreadLocal.remove().

Q13. How would you investigate high GC overhead, or long pauses, in the logs?

Short answer:

1. Quantify it: GC time % and pause distribution (p50/p99/max), from the logs or GCeasy.
2. Classify the pauses: young vs mixed vs full, and their causes (evacuation failure, humongous allocation, Metadata GC Threshold, System.gc()).
3. Check the phases (-Xlog:gc+phases=debug): object copy (a large survivor set), ref processing (lots of soft or weak references or finalizers), code root scanning, and time-to-safepoint.
4. Check the environment: container CPU throttling (cgroup nr_throttled), swapping, transparent huge pages, noisy neighbours, too few GC threads.
5. Check allocation: JFR allocation profiling for a sudden allocation-rate increase after a deployment.
6. Act: reduce allocation, give heap headroom, fix humongous allocations or leaks, tune the pause target, remove explicit GCs, or switch to generational ZGC for latency.

Q14. How do you analyse and address OutOfMemoryErrors in your logs?

Short answer: First read the message, because each type has a different cause:

Then reproduce it (a load or soak test), fix the root cause, and only then resize. Add -XX:+ExitOnOutOfMemoryError, so a broken JVM is restarted cleanly.

Q15. How do you analyse and fix a memory leak? How do you debug one? (The combined answer)

Short answer:

• Tools: heap dumps and MAT (the definitive answer to who holds what), JFR Old Object Sample (where it was allocated), class histograms over time (what grows), and NMT for native memory.
• Fixes, by pattern:
  • Unbounded collections or caches: add limits and eviction.
  • Listeners and callbacks: unregister them, or use weak listeners.
  • ThreadLocal: remove() in finally.
  • Resources: try-with-resources for streams, JDBC objects and HTTP responses.
  • Long-lived objects referencing short-lived ones: break the reference (scope them properly, or store IDs).
  • Class loaders: clean up threads, drivers and MBeans.
• Weak references are a tool, not a universal fix. Use them where the semantics fit (canonicalising maps, metadata attached to objects).
• Verify with a soak test, checking that the post-GC floor is flat, and add a regression alert.

Q16. How would you structure code to avoid memory leaks in a long-running application?

Short answer:

• Own every lifecycle: everything you register (listeners, schedulers, threads, MBeans, subscriptions) has a matching unregister, tied to @PreDestroy/close(). Prefer scoped constructs (try-with-resources, structured concurrency).
• Bounded structures only: caches with size limits and TTLs, bounded queues, bounded executors.
• No static mutable state except well-defined, bounded registries.
• ThreadLocal discipline: set and remove in try/finally (filters, interceptors). Prefer ScopedValue (finalised in Java 25) for per-request context.
• Streams and pagination for large data. Don't collect entire tables into memory.
• Don't keep references to request or response objects in long-lived components (async callbacks, caches).
• Observability: heap-after-GC metrics, cache size metrics, and continuous JFR, so leaks are caught early.

Q17. What is jstack used for?

Short answer: jstack <pid> prints a thread dump: every thread's name, state (RUNNABLE, BLOCKED, WAITING, TIMED_WAITING), stack trace, and locks held or awaited. It also reports Java-level deadlocks. Modern equivalents: jcmd <pid> Thread.print, and jcmd <pid> Thread.dump_to_file -format=json, which includes virtual threads (Java 21). You can also send kill -3 <pid> (the dump goes to stdout).

Use it for: hangs, deadlocks, thread-pool exhaustion, and high CPU (map a hot OS thread ID from top -H to the dump's nid, in hex). Take 3–5 dumps a few seconds apart: threads stuck in the same frame across dumps are your suspects.

Q18. How do you debug thread contention?

Short answer:

1. Symptoms: throughput plateaus while CPU isn't saturated, latency rises under load, many threads BLOCKED or parked.
2. Thread dumps (several): look for many threads waiting to lock <0x...> on the same monitor, or parked on the same ReentrantLock/AbstractQueuedSynchronizer. Identify the owner, and what it's doing (often slow I/O inside a lock).
3. JFR: jdk.JavaMonitorEnter (with blocked duration and stack traces), jdk.ThreadPark, and JMC's Lock Instances view. Or use async-profiler's -e lock mode.
4. Virtual threads: jdk.VirtualThreadPinned events show pinning, which in Java 21–23 was typically caused by blocking inside synchronized or native frames.
5. Fixes:
   • Shrink the critical sections.
   • Move I/O out of locks.
   • Stripe the locks, or use concurrent structures (ConcurrentHashMap, LongAdder).
   • Read-mostly data: copy-on-write, or StampedLock optimistic reads.
   • Remove shared mutable state altogether (partitioning or thread confinement).
   • Correctly sized pools (connection pools are a common hidden lock).

Follow-up questions this topic invites — and their answers

Q: What's the difference between shallow size and retained size in MAT? A: Shallow size is the object's own memory. Retained size is the memory that would be freed if the object were collected: everything only reachable through it. Leak hunting focuses on large retained sizes (the dominator tree).

Q: Can you take a heap dump without stopping the application? A: Not completely. Heap dumping needs a safepoint for consistency, so the JVM pauses for the dump's duration. Minimise the impact by draining traffic first, dumping to fast local disk, and avoiding the live option when you don't need the Full GC first.

Q: What is Native Memory Tracking (NMT)? A: A JVM feature (-XX:NativeMemoryTracking=summary|detail) that accounts for the JVM's own native allocations by category (heap, class, thread, code, GC, internal, other). Query it with jcmd <pid> VM.native_memory summary, with a baseline and diff to see growth. It doesn't track allocations by third-party native libraries.

Q: What is async-profiler, and why is it popular? A: An open-source, low-overhead sampling profiler for HotSpot. It combines AsyncGetCallTrace with Linux perf events, so it has no safepoint bias, covers CPU, allocation, lock and wall-clock modes, includes native and kernel frames, and outputs flame graphs.