Stack vs Heap Memory in Java

The stack holds local variables and the frames of running methods. Each time you call a method, the JVM pushes a frame containing that method's parameters, its local variables and the bookkeeping needed to return; when the method returns, the frame is popped and its memory is reclaimed immediately. The stack is fast, thread-local and self-managing, and its size is fixed by the thread stack size, usually a megabyte or so per thread.

The heap holds all objects — every instance you create with new, every array, every String, every collection. The heap is shared between threads, it is managed by the garbage collector, and its size is governed by the maximum heap size passed to the JVM. Nothing in your source code decides where an object lives; the only thing that lives on the stack is the reference variable pointing at it.

The consequence worth internalising is that the reference and the object are in different places. A local variable of a reference type is a slot on the stack holding an address; the object it addresses lives on the heap. That is why a method can hand you a reference to an object and then lose its own reference to it — the object is still alive as long as your reference keeps it reachable.

One clarification that interviewers often probe: primitives declared as locals also live in the stack frame, and their values are copied on every call, so reassigning a local primitive has no effect outside the method. Primitive fields are different — they live inside the heap object that declares them.

A local variable lives in the stack frame of the method that declares it. If its type is a reference type, the stack slot holds an address. The object itself lives on the heap, and the object's own fields live inside that heap object. Primitives declared as fields are stored directly in the object rather than as separate references.

public class Main {
    static int staticCounter = 1;   // lives with the class, not in a stack frame

    public static void main(String[] args) {
        int local = 42;                 // stack frame of main
        Point p = new Point(3, 4);      // p is on the stack, the Point is on the heap
        System.out.println("local  = " + local);
        System.out.println("point  = " + p);

        // A second reference to the same heap object.
        Point alias = p;
        alias.x = 99;
        System.out.println("after alias.x = 99, p.x = " + p.x);

        // Reassigning the local reference leaves the object alone.
        p = new Point(7, 8);
        System.out.println("after reassign, alias.x = " + alias.x);
        System.out.println("p is now      : " + p);
    }
}

class Point {
    int x, y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public String toString() {
        return "Point(" + x + ", " + y + ")";
    }
}

The output is the whole lesson in four lines. Setting alias.x = 99 changes the shared object, so p.x becomes 99 as well. Reassigning p to a brand-new Point changes only the stack slot, so alias still points at the original object with x equal to 99, while p now refers to the new Point.

Two corollaries follow. The garbage collector cannot reclaim an object while any reachable reference points at it, which is exactly how the alias above keeps the first Point alive. And because the stack is reclaimed the instant a method returns, a local reference disappears at that moment while the object it pointed at survives until the collector notices it is unreachable.

Both are Errors, not Exceptions, and both mean the JVM ran out of a resource — but they run out of different resources and are fixed in different ways.

A StackOverflowError means the call stack is exhausted. Each nested call consumes a stack frame, and the JVM throws the error when the stack cannot grow any further, which happens on deep recursion with no terminating condition. The classic example is infinite recursion, but real cases are subtler: recursive tree walks over a deep structure, a toString implementation that calls itself, or a equals method that delegates back to the other object. The fix is to remove the unbounded recursion — add a base case, rewrite the algorithm iteratively, or split the work into smaller steps. Increasing the thread stack size with the -Xss flag postpones the problem rather than solving it.

An OutOfMemoryError means the heap is exhausted. Objects are still strongly reachable, so the collector cannot reclaim them. The usual causes are a genuine leak — a collection that grows without bound, a static cache that never evicts, a listener registered and never removed — or simply a workload that needs more heap than was allocated, in which case raising -Xmx is the correct response.

The distinction that matters in practice: a StackOverflowError's stack trace shows the same few frames repeated thousands of times, which points straight at the recursion. An OutOfMemoryError gives you a stack trace at the point of allocation plus a message that names the pool, and a heap dump is needed to find the retainer. Because OutOfMemoryError is an Error, a catch block for Exception will not catch it, and a catch-all is often the wrong fix; the right move is usually to let the process die and be restarted by a supervisor.