JVM, Memory & Class Loading — Interview Questions

How to use this lesson

At this level, interviewers expect you to connect JVM internals to production symptoms: Metaspace growth after redeploys, a heap that climbs until OutOfMemoryError, a flag one thread never sees. Answer with the mechanism, and then the tool you'd use to confirm it.

Q1. How are strings represented in memory?

Short answer: A String object holds a byte[] plus a coder flag. Since Java 9 (compact strings), text that fits in Latin-1 uses one byte per character, and anything else uses UTF-16 (two bytes per character). Strings are immutable, cache their hash code, and literals are interned in the string pool, which lives on the regular heap (since Java 7).

Key points to cover:

• Before Java 9, a String wrapped a char[], with 2 bytes per character even for ASCII. The change roughly halved string memory in typical applications.
• G1 can deduplicate the backing arrays of equal strings (-XX:+UseStringDeduplication).
• substring has copied its characters since Java 7u6. The old behaviour shared the parent's array, and could leak huge strings.

Learn it in depth → JVM Memory Areas

Q2. How do JVM optimisations affect application performance?

Short answer: The JVM starts out interpreting bytecode, profiles what actually runs, and JIT-compiles the hot methods to optimised native code. The main optimisations:

• Inlining: removes call overhead, and enables further optimisations.
• Escape analysis: allocates non-escaping objects on the stack, or eliminates them entirely, and removes unnecessary locks.
• Loop unrolling, and vectorisation (SIMD).
• Dead-code elimination.
• Speculative optimisations, with deoptimisation if their assumptions break.

Tiered compilation (the C1 compiler, then C2) balances startup speed against peak performance.

Key points to cover:

• Warm-up: peak performance arrives only after the JIT has compiled the hot paths. Benchmarks need warm-up (use JMH), and new pods can be slow for their first few thousand requests.
• Startup options: Class Data Sharing (AppCDS), CRaC checkpoints, GraalVM native image, and Project Leyden's ahead-of-time caches (JDK 24+).

Learn it in depth → GC Tuning & Diagnostics

Q3. How do JVM optimisations affect performance? (Common follow-up: what can defeat them?)

Short answer: The same mechanisms as Q2. The follow-up is what makes them fail:

• Megamorphic call sites (many implementations at one call site) prevent inlining.
• Huge methods exceed the inlining limits.
• Frequently thrown exceptions and heavy reflection slow down hot paths.
• Excessive allocation raises GC pressure.
• Deoptimisation storms happen when speculative assumptions keep being invalidated, for example when classes load late and change the class hierarchy.

Key points to cover:

• Diagnose with async-profiler or JFR, not guesswork. -XX:+PrintCompilation shows JIT activity.

Q4. What is a class loader, and how does class loading work?

Short answer: A class loader finds a class's bytes and turns them into a Class object. Loading is lazy: a class loads when it's first actively used. There are three built-in loaders, arranged in a parent-delegation hierarchy:

• Bootstrap: core java.base classes. It's native, and appears as null in Java code.
• Platform: the other Java SE modules. Before Java 9 this was the Extension loader.
• Application (system): your classpath and module path.

A loader first asks its parent, and loads the class itself only if the parent can't. The phases are: loading → linking (verification, preparation, resolution) → initialisation (static initialisers run).

Key points to cover:

• A class's runtime identity is (fully qualified name + defining class loader). The same class loaded by two loaders gives two distinct types. That's the source of "cannot cast com.x.Foo to com.x.Foo" errors in app servers and plugin systems.
• Frameworks create custom loaders: app servers (per web app), OSGi, Spring Boot's LaunchedClassLoader for nested JARs, and DevTools' restart class loader.

Q5. Can you unload a class?

Short answer: Not directly. A class is unloaded only when its defining class loader becomes unreachable, and so do all its classes, their instances and their Class objects. Classes loaded by the bootstrap, platform or application loaders are effectively never unloaded.

Key points to cover:

• Unloading matters for redeploys in app servers, and for plugin systems. A single leftover reference, such as a ThreadLocal, a JDBC driver registered in DriverManager, a static cache or a running thread, keeps the whole old class loader alive. That's the classic "Metaspace grows after each redeploy" leak.

Q6. Is it possible to unload a class? (Follow-up: how would you verify it happens?)

Short answer: Yes, but only through class-loader unloading, as in Q5. To verify it:

• Log class unloading with -Xlog:class+unload.
• Watch Metaspace usage in JFR, or jcmd <pid> VM.metaspace.
• Take a heap dump, and look for multiple instances of your web app's class loader (Eclipse MAT's "duplicate classes" and class-loader views).

Q7. How does class loading affect memory usage?

Short answer: Each loaded class consumes Metaspace (native memory) for its metadata, bytecode, constant pool and JIT data. Its Class object and static fields live on the heap. Large frameworks, dynamically generated proxies (CGLIB, lambdas, Hibernate) and class-loader leaks all increase this footprint.

Key points to cover:

• Cap Metaspace with -XX:MaxMetaspaceSize, so that a leak fails fast instead of consuming container memory.
• Container memory limits must account for heap + Metaspace + thread stacks + code cache + direct buffers. The JVM's footprint is bigger than -Xmx.

Q8. How does class loading affect memory? (Repeated question: answer from the operations angle)

Short answer: In production, the symptoms are OutOfMemoryError: Metaspace, or a pod killed for exceeding its memory limit while the heap looks fine. The causes: too many generated classes (for example, unbounded dynamic proxies or scripting engines), or class-loader leaks on redeploy. Mitigations:

• Fix the leak.
• Avoid generating classes in loops.
• Reuse script engines.
• Set Metaspace limits.
• Use Native Memory Tracking (-XX:NativeMemoryTracking=summary plus jcmd VM.native_memory) to see where off-heap memory goes.

Q9. How does Java deal with memory leaks?

Short answer: The garbage collector frees unreachable objects automatically. But a Java "memory leak" is objects that are still reachable but no longer needed, and no GC can fix that. Typical causes:

• Static or long-lived collections that only grow.
• Caches without eviction.
• Listeners that are never unregistered.
• ThreadLocal values left in thread pools.
• Unclosed resources.
• Inner classes capturing their outer object.
• Mutable HashMap keys.

Key points to cover:

• Prevention:
  • Bounded caches (Caffeine with a size limit or TTL).
  • try-with-resources.
  • remove() for ThreadLocals in finally.
  • Weak references where appropriate.
  • Static nested classes.

Learn it in depth → Memory Leaks in Java

Q10. What tools and techniques help identify and fix memory leaks?

Short answer:

1. Confirm the pattern. GC logs or metrics show the old generation's floor rising after every full GC.
2. Capture a heap dump with jcmd <pid> GC.heap_dump file.hprof, or automatically with -XX:+HeapDumpOnOutOfMemoryError.
3. Analyse it in Eclipse MAT: the Leak Suspects report, the dominator tree (what retains the most memory), and the path to GC roots.
4. Compare two dumps taken over time, to see what grows.

Other tools: JFR (the Old Object Sample event finds long-lived objects cheaply in production), VisualVM, JProfiler and YourKit, async-profiler's allocation mode, and jmap -histo for a quick class histogram.

Q11. Describe the Java Memory Model.

Short answer: The JMM defines what values a read is allowed to see when several threads share variables. It allows compilers and CPUs to reorder and cache operations for speed, except across happens-before edges:

• program order within a thread;
• unlocking a monitor → a later lock of the same monitor;
• a volatile write → later reads of that variable;
• Thread.start() → the actions of the started thread;
• a thread's actions → another thread's return from join() on it;
• the final-field freeze at the end of a constructor.

If two accesses to shared data aren't ordered by happens-before, and at least one is a write, you have a data race, and the results are unpredictable.

Key points to cover:

• The JMM gives you three guarantees to reason about: atomicity (which operations are indivisible), visibility (when writes become visible) and ordering (which reorderings are forbidden).

Learn it in depth → Volatile and the Java Memory Model

Q12. What is the visibility problem?

Short answer: Without synchronisation, a write made by one thread may never become visible to another thread, or may become visible late or out of order. The JIT can hoist a read out of a loop, keep a value in a register, or reorder writes. The classic example is a stop flag the worker thread never sees:

class Worker implements Runnable {
    private boolean running = true;              // not volatile
    public void run() { while (running) { } }    // the JIT may turn this into while(true)
    void stop() { running = false; }             // may never be observed
}

Key points to cover:

• Fixes: volatile, synchronized or locks, atomic classes, or the concurrent collections. All of them establish happens-before edges.
• "Thread-local CPU caches" is a common simplification. The real culprits are compiler and CPU reordering and register allocation. Hardware caches are coherent.

Q13. How does garbage collection handle circular references?

Short answer: Without any trouble. The JVM's collectors use reachability tracing from GC roots, not reference counting. Objects that reference each other in a cycle, but can't be reached from any root, are simply never marked, and they get collected.

Key points to cover:

• Reference-counting systems (CPython's refcounting, or Swift's ARC) need cycle detectors or weak references for this. Java doesn't.

Q14. How does the static keyword affect memory management?

Short answer: Static fields are allocated once per class (per class loader), when the class is initialised. Since Java 8 they're stored on the heap, together with the class's java.lang.Class object. The class's metadata lives in Metaspace. Static fields are GC roots for as long as the class is loaded, which in practice means for the application's lifetime. Anything a static field references stays alive.

Common trap: "static data lives in the method area / PermGen". PermGen was removed in Java 8. Statics moved to the heap, and metadata moved to Metaspace.

Key points to cover:

• That's why static collections are the number-one source of memory leaks: whatever they reference can never be collected until it's removed.

Follow-up questions this topic invites — and their answers

Q: What's the difference between Metaspace and the heap? A: The heap holds objects, and is limited by -Xmx. Metaspace holds class metadata in native memory. It grows dynamically, and can be capped with -XX:MaxMetaspaceSize.

Q: What is ClassNotFoundException vs NoClassDefFoundError, from a class-loading perspective? A: ClassNotFoundException means an explicit dynamic load (Class.forName, loadClass) couldn't find the class. NoClassDefFoundError means the JVM needed a class that was present at compile time, but it's missing now, or its static initialisation previously failed.

Q: How do you get a heap dump from a container that just crashed with OOM? A: Configure -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps, with /dumps mounted on a persistent volume. Otherwise, the dump dies with the container.

Q: What does escape analysis do? A: The JIT determines whether an object ever escapes its method or thread. If not, it can scalar-replace it (no heap allocation at all), and remove locks on it (lock elision). That's one reason short-lived objects are so cheap in Java.