StackOverflowError vs OutOfMemoryError in Java

StackOverflowError and OutOfMemoryError are Java's two most common JVM-level fatal errors — they affect completely different memory regions, have different root causes, and require entirely different diagnosis approaches.

StackOverflowError:

• A single thread's call stack runs out of space — almost always from infinite or very deep recursion
• Stack trace shows the recursive method directly — straightforward to diagnose
• Fix: add a base case or convert to iteration; increasing -Xss rarely helps

OutOfMemoryError subtypes:

• "Java heap space": GC can't free enough memory — either a leak (post-GC live set grows over time) or undersized heap (post-GC live set stable)
• "Metaspace": classloader leak — common during hot redeployment in app servers
• "GC overhead limit exceeded": JVM spends 98% of time collecting less than 2% — effectively a leak under pressure
• "unable to create native thread": unbounded thread creation exhausted OS thread limits

Both extend Error:

• Signals the JVM is in a state you generally cannot safely recover from — don't catch and continue

I recommend setting -XX:+HeapDumpOnOutOfMemoryError in every production deployment — the snapshot is essential for root cause analysis and you don't want to scramble to reproduce after a container restart.