What are the main JVM memory areas?

The JVM splits runtime memory into several areas. The most important ones to understand for interviews are the heap, JVM stack, method area, PC register, and native method stack.

The big mental model is simple: some memory is shared by all threads, while some memory is private to each thread.

JVM memory areas explain common production and interview topics:

• Why recursive code can cause StackOverflowError
• Why too many objects can cause OutOfMemoryError
• Why local variables are naturally thread-private
• Why shared objects need concurrency control
• Why garbage collection mostly focuses on heap memory

The heap is the runtime area where Java objects and arrays are allocated. It is shared across all JVM threads.

User user = new User("Asha");

// The reference variable "user" may be local to a method,
// but the User object itself lives on the heap.

This is where many beginners get confused. The local variable may be on a stack frame, but the actual object created with new is on the heap.

Each thread has its own JVM stack. Every method call creates a stack frame. That frame holds things like local variables, intermediate results, and information needed to return from the method.

public int addTax(int price) {
    int tax = 5;
    return price + tax;
}

The method area stores class-level information: class metadata, method information, field information, bytecode for methods and constructors, and runtime constant pool data.

A useful way to think about it: heap stores objects, while the method area stores information about classes.

Each thread has a program counter, often called the PC register. It tracks the current JVM instruction being executed by that thread.

You usually do not directly think about the PC register in day-to-day Java coding, but it is part of the JVM runtime model and helps explain how each thread can be executing different code independently.

The native method stack is used when Java code calls native methods, such as code written in C or C++ through JNI.

For most backend interview discussions, it is enough to know that this exists for native execution and is separate from the ordinary Java method-call stack.