Heap vs Stack Memory
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Heap and stack are different JVM memory areas. The heap is shared by all threads and stores class instances and arrays. Each thread has its own JVM stack, which contains a frame for every active method call.
For example, in Person person = new Person(), the local variable person is a reference in the current method frame. The Person object itself is on the heap. A primitive local value can be in a frame, while a primitive field is part of its object.
Their lifetimes are also different. A frame is removed when its method finishes. A heap object can remain after that method returns if a field, collection, returned reference, or another live path still reaches it.
Deep or endless calls can cause StackOverflowError. If the JVM cannot provide enough heap storage, it can throw OutOfMemoryError. The simple rule is: stacks hold one thread's active calls, while the heap holds shared objects and arrays.
Heap vs Stack Memory
Direct Answer
The JVM heap is shared by all threads and is the logical storage for class instances and arrays. Every JVM thread has a private JVM stack made of frames for its active method calls. A frame carries local variables, an operand stack, and method-execution data; it disappears when that call completes.
Deep Dive & Architecture
Call stacks and heap objects
Suppose createOrder() constructs an Order, stores the reference in a service field, and returns. The method call has a frame containing its parameters, temporary values, and the local Order reference. That frame ends on return. The Order remains reachable through the service field, so it is not garbage just because the creating method finished.
If the method returns the reference instead, the caller receives a copy of the reference value before the callee frame disappears. If the method neither returns nor stores it, and no other path exists, the Order can become eligible for collection. Eligibility still does not mean immediate collection.
Memory areas and their common failures
A recursive traversal creates another frame for every unfinished call. With enough depth, one thread may reach its allowed stack limit and throw StackOverflowError even while plenty of heap remains. A program retaining millions of Orders can instead exhaust heap capacity and throw OutOfMemoryError even with shallow call stacks. The error points to a runtime area, while logs and traces reveal the actual cause.
Logical memory areas and runtime optimisations
If an object's identity never escapes and is unobservable, an optimizing JVM may eliminate the allocation or break it into scalar values. This does not change Java-level behaviour and is not storage an application can request. The JVM specification defines logical areas rather than one universal RAM map, so avoid fixed claims about addresses, default stack sizes, or which allocation is “always faster” without naming a runtime and measurement.
Code Example
class HeapAndStackMemory {
record User(String name) {}
static User createUser(String name) {
User localReference = new User(name);
return localReference;
}
public static void main(String[] args) {
User returnedReference = createUser("Mina");
System.out.println(returnedReference.name());
}
}
After createUser returns, its frame is gone. The User is still reachable from returnedReference in the caller.
Check your understanding
Answer these without looking back at the article.
- Does a local object reference mean the object is stored on the stack?
- Why can a heap object outlive the method that created it?
- Which failures normally point to stack and heap exhaustion?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.