How does StackOverflowError differ from OutOfMemoryError, and how do you tell which one you are facing?

## The shared parent Both `StackOverflowError` and `OutOfMemoryError` extend `java.lang.VirtualMachineError`, which extends `Error`. So both are **Errors**, not Exceptions: they signal serious JVM-level resource exhaustion that you normally fix at the source rather than catch and continue. But they describe **different memory regions** and have **different causes and fixes**. ## JVM memory regions (the background you need) - **Heap** — where objects created with `new` live; shared by all threads; sized with `-Xms` (initial) and `-Xmx` (max); reclaimed by the garbage collector (GC). - **Metaspace** — native memory holding class metadata (the structure of loaded classes); sized with `-XX:MaxMetaspaceSize`. - **Thread stacks** — each **thread** has its own fixed-size stack of **frames** (one per active method call); sized with `-Xss`. This is **not** the heap. ## StackOverflowError Thrown when a thread tries to push a new stack frame but its stack is full. Cause: almost always **unbounded recursion** (missing base case, mutual recursion, accidental self-call) or **legitimately very deep** recursion, or unusually **large frames**. It affects **one thread's stack** only. Signature in the trace: the **same method (or a short cycle) repeating** over and over — that repetition is the giveaway. Fix: correct the base case, or **convert recursion to iteration** so depth lives on the heap, not the stack; `-Xss` can give a little headroom but cannot cure infinite recursion. ## OutOfMemoryError Thrown when the JVM cannot allocate within a managed pool. It comes in flavours identified by the message: - **`Java heap space`** — the heap is full of **live** (reachable) objects; commonly a **memory leak** (objects kept reachable forever, e.g. an ever-growing cache or static collection) or simply a heap too small for the workload. Fix: find and break the retention (heap dump + analyzer), reduce footprint, or raise `-Xmx`. - **`GC overhead limit exceeded`** — the GC is running almost constantly but reclaiming almost nothing; effectively a near-full heap. - **`Metaspace`** — too much class metadata, often from **classloader leaks** (e.g. repeated redeploys retaining old classloaders). Fix: raise `-XX:MaxMetaspaceSize` or fix the leak. - **`unable to create native thread`** — the OS won't grant more threads; ironically often relieved by a **smaller** `-Xss` (each thread reserves less) or fewer threads. ## How to tell them apart in practice 1. **Read the message line.** `java.lang.StackOverflowError` vs `java.lang.OutOfMemoryError: <region>` is immediate. 2. **Read the trace shape.** StackOverflow: the same frames repeating to enormous depth. OOM: a normal-depth trace at the allocation site, plus the named region. 3. **Look at the fix you'd reach for.** Recursion bug → StackOverflow. Leak / retention / undersized heap → OOM. ## Why the distinction matters They point at **opposite remedies**. Raising `-Xmx` (heap) does nothing for a recursion bug; raising `-Xss` (stack) does nothing for a heap leak — and on a thread-starved system, raising `-Xss` can make 'unable to create native thread' *worse*. Misdiagnosing wastes effort and can hide the real defect.