MediumJava#18 min readJul 11, 2026
Explain JVM architecture.
practice
Practice modeTest yourself instead of reading straight through
Interviewers love this because JVM architecture explains why Java is both portable and fast enough for production.
Question: Explain JVM architecture.
Answer: The JVM is the runtime engine that executes Java bytecode. It is made of a class loader subsystem, runtime memory areas, an execution engine, and support for native calls. In simple words, it loads classes, keeps track of memory, runs your code, and cleans up unused objects.
Interview-Ready Answer: I think of the JVM as the engine behind Java bytecode. First, the class loader loads classes, then the JVM links and initializes them, and after that the execution engine runs the bytecode using an interpreter and JIT compiler. The runtime memory is split into areas like the heap and per-thread stacks, and the garbage collector reclaims unused objects. One detail I like to mention is that since Java 8, class metadata lives in Metaspace, which is native memory, not the heap.
%22%20stroke%3D%22%234f46e5%22%20stroke-width%3D%221.5%22%2F%3E%3Ctext%20x%3D%22500%22%20y%3D%22308%22%20text-anchor%3D%22middle%22%20font-size%3D%2215%22%20font-weight%3D%22bold%22%20fill%3D%22%23ffffff%22%20font-family%3D%22Segoe%20UI%2C%20Arial%2C%20sans-serif%22%3EJVM%20Architecture%3C%2Ftext%3E%3C%2Fsvg%3E)
Big picture
The JVM is what makes Java bytecode run on different operating systems without recompiling the source. Bytecode is the platform-neutral instruction set produced by javac. The JVM itself is a specification, and HotSpot is the most common implementation you will meet in interviews and production.
How it works under the hood
- Compilation happens first. Your
.javafile is compiled into a.classfile containing bytecode. The JVM does not read Java source directly. - The class loader subsystem loads classes on demand. It usually starts with the Bootstrap loader for core Java classes, then the Platform loader, then the Application loader for your app classes. This is why classes are not all loaded upfront; they are brought in when needed.
- Linking prepares the class for use. Linking has three steps: verification checks bytecode safety, preparation allocates memory for static fields and sets default values, and resolution replaces symbolic references with direct references. Symbolic reference means a name like
java/lang/String; direct reference means the JVM has found the actual target. - Initialization runs static code. Static field initializers and static blocks execute once, in a well-defined order. This is where class-level setup happens.
- Execution uses the runtime data areas. Every thread gets its own JVM stack and program counter register. The stack is made of frames (a frame is the data for one method call): local variables, operand stack, and return info. Shared areas like the heap store objects and arrays.
- The execution engine runs bytecode. It can interpret bytecode instruction by instruction at first, then the JIT compiler (just-in-time compiler, meaning it turns hot bytecode into native machine code while the program is running) compiles frequently used methods for speed. Compiled code is stored in the code cache.
- Garbage collection reclaims memory. The GC finds objects that are no longer reachable from live references and frees their heap memory. Some collectors also compact memory to reduce fragmentation. GC mainly manages the heap, not every byte of native memory.
- JNI bridges to native code. JNI stands for Java Native Interface. It lets Java call OS or C/C++ libraries when you need platform-specific or legacy functionality.
Runtime memory areas you should know
| Area | Shared? | What it stores | Common failure |
|---|---|---|---|
| JVM Stack | No | Method frames, locals | StackOverflowError |
| Heap | Yes | Objects, arrays | OutOfMemoryError |
| Metaspace | Yes | Class metadata | OutOfMemoryError: Metaspace |
| Code Cache | Yes | JIT code | Slower execution |
One version difference is important: in Java 7 and earlier, class metadata was typically stored in PermGen; in Java 8 and later, PermGen was removed and replaced by Metaspace in native memory. That is a favorite interview detail.
Performance and edge cases
- Class loading cost is roughly proportional to how many classes and dependencies you load.
- Each thread stack is limited; on many 64-bit JVMs the default stack size is often around 1 MB, but it depends on the OS, JVM vendor, and
-Xsssetting. - Heap size is tuned with
-Xmsand-Xmx; if the heap is too small, GC runs more often, and if it is too large, pauses can become expensive depending on the collector. - Deep or accidental recursion can end in
StackOverflowError; leaking class loaders can grow Metaspace untilOutOfMemoryError: Metaspaceappears.
Memory hook: think of the JVM as a theater: the class loader is the usher, the memory areas are the backstage rooms, the execution engine is the actor, and GC is the cleanup crew.
Real-world story
Imagine a checkout service for an e-commerce site. A developer adds a static in-memory cache of every product detail, thinking it will reduce database calls. At first the service is fast, but over hours the heap grows, GC runs more often, p99 latency jumps, and eventually the service starts returning 502 errors because the JVM throws OutOfMemoryError: Java heap space.
What does this look like in production? The logs may show long GC pauses, frequent young and full GCs, and the process may become unresponsive before it dies. Users see slow cart updates or failed payments, and the team may restart the pod only to see the memory climb again. The root cause is not "Java is slow"; it is usually a JVM memory misunderstanding, such as keeping references alive too long, using a cache without limits, or loading classes repeatedly with leaking class loaders.
A related outage happens in plugin-based systems: if a class loader is kept alive after redeploy, old classes cannot be unloaded, Metaspace keeps growing, and the app fails with OutOfMemoryError: Metaspace. That is why understanding JVM architecture matters in real production debugging, not just interviews.
Java
import java.util.ArrayList;
import java.util.List;
public class JvmArchitectureDemo {
// A static block runs when the class is initialized.
// This helps show the "class loading + initialization" part of the JVM lifecycle.
static {
System.out.println("[class initialization] Static block ran once.");
}
// Small object to show that objects live on the heap, not in stack frames.
private static final class Session {
private final String userId;
private final byte[] payload;
Session(String userId, int payloadKb) {
this.userId = userId;
// Allocate heap memory so the object is clearly non-trivial.
this.payload = new byte[payloadKb * 1024];
}
@Override
public String toString() {
return userId + "(" + (payload.length / 1024) + "KB)";
}
}
public static void main(String[] args) {
System.out.println("=== JVM architecture demo ===");
// Heap: these objects are allocated in the shared heap area.
List<Session> sessions = new ArrayList<>();
sessions.add(new Session("alice", 64));
sessions.add(new Session("bob", 64));
System.out.println("Heap objects: " + sessions);
// Stack: these variables live in the current method frame.
int a = 10;
int b = 20;
System.out.println("Stack locals sum: " + add(a, b));
// Failure path: unbounded recursion consumes the current thread's stack.
// We catch StackOverflowError only to show the JVM limit safely in a demo.
try {
recurseForever(1);
} catch (StackOverflowError e) {
System.out.println("Caught StackOverflowError: a thread stack has a finite size, so deep recursion eventually fails.");
}
}
private static int add(int x, int y) {
return x + y;
}
private static int recurseForever(int depth) {
if (depth % 5000 == 0) {
System.out.println("Recursion depth = " + depth);
}
// No base case on purpose: this demonstrates how the JVM stack can overflow.
return 1 + recurseForever(depth + 1);
}
}Follow-up & Tricky Questions:
- How is JVM different from JRE and JDK? The JVM is the runtime that executes bytecode. The JRE includes the JVM plus standard libraries, and the JDK includes the JRE plus development tools like
javacandjcmd. - What is the difference between stack and heap? The stack is private to each thread and stores method frames and local variables. The heap is shared by all threads and stores objects and arrays.
- What happens during class loading? The JVM loads the class, verifies bytecode, prepares static memory, resolves references, and then initializes the class by running static initializers.
- Why do we need JIT if we already have an interpreter? The interpreter starts fast, but JIT compiles hot code into native machine code so frequently executed paths run much faster over time.
- How does garbage collection fit into the JVM architecture? The GC manages heap memory by finding unreachable objects and reclaiming them. Different collectors trade off throughput, pause time, and CPU usage.
- Is Metaspace part of the heap? No. Since Java 8, Metaspace is stored in native memory outside the heap, which is why class metadata problems can fail differently from ordinary heap leaks.
- Is String stored on the stack or heap? The
Stringobject is on the heap; a local reference to it may be on the stack. In modern Java, string literals are managed through the string pool, which lives on the heap. - Does GC free stack memory? No. Stack frames disappear automatically when a method returns, but GC is about heap objects, not thread stacks.
- Is the JVM the same as HotSpot? No. The JVM is the runtime concept/specification, while HotSpot is one specific implementation used by most Java applications.
Tricky / gotcha questions:
- Can a JVM run without JIT? Yes. It can interpret bytecode only, but performance is usually worse because hot code is not optimized into native machine code.
- Does removing all references always free memory immediately? Not immediately. The object becomes eligible for GC, but the collector decides when to reclaim it.
- Can class loading cause memory leaks? Yes. If a custom class loader is accidentally kept alive, its classes cannot be unloaded and Metaspace can grow over time.
Common Mistakes:
- Thinking JVM, JRE, and JDK are the same thing. Correction: JVM runs bytecode, JRE packages the runtime, and JDK adds development tools.
- Saying all memory is "the heap." Correction: thread stacks, Metaspace, and code cache are separate areas with different jobs.
- Forgetting the class loader/linking/initialization sequence. Correction: loading is not just "read the file"; the JVM verifies and prepares classes before execution.
- Believing GC fixes every memory problem. Correction: GC mainly reclaims heap objects; native memory leaks and class loader leaks need different debugging.
Memory Hook: Think of the JVM as a restaurant: the class loader is the host, the heap and stacks are the kitchen stations, the JIT is the chef who gets faster after learning the menu, and GC is the cleanup crew after service.
Cheat Sheet:
- JVM runs bytecode, not Java source.
- Core parts: class loader, runtime memory, execution engine, JNI.
- Per-thread: stack and PC register.
- Shared: heap, metaspace, code cache.
- Interpreter starts fast; JIT makes hot code fast.
- GC reclaims unreachable heap objects; deep recursion can still cause
StackOverflowError.
Practice Tasks:
- Draw the JVM architecture from memory and label each memory area.
- Write a small recursive method and explain why it can fail with
StackOverflowError. - Set a small heap with
-Xmxin a test app and observe how memory pressure changes GC behavior.