昨天，老粉阿强（是的，他还没找到工作）去面了某独角兽公司的中间件团队。
面试官问了一个看似基础、实则暗藏杀机的 JVM 题目：
“请说一下StackOverflowError和OutOfMemoryError的区别？如果线上发生了 StackOverflowError，JVM 进程会退出吗？”
阿强心想，这不就是考单词拼写吗？自信满满地回答：
“一个是栈溢出，一个是堆溢出呗！既然都是Error结尾的，属于严重错误，肯定会导致 JVM 崩溃重启啊！”
面试官听完，合上简历，冷冷地说：
“回去等通知吧。你对 Java 线程模型的理解，连门都没入。”
兄弟们，这道题的通过率极低。
很多人只知道它们“发生在哪”，却不知道它们的“爆炸半径”完全不同。
今天 Fox 就带大家从底层原理到业务场景，彻底拆解这对“JVM 双煞”。
一、 核心本质：私有领地 vs 公共广场
要理解它们的死法不同，必须先看一眼JVM 运行时数据区。
我们可以把 JVM 想象成一家大公司：
- 虚拟机栈 (Java Stack) —— 员工的工位 (线程私有)
每个线程（员工）都有自己独立的工位。
你在工位上堆满了文件（栈帧深度过大），只会导致你自己没法工作。
- 关键点：
你的工位炸了，通常不会影响隔壁同事的工位。
- 堆内存 (Java Heap) —— 公司食堂 (线程共享)
所有线程（员工）共用一个食堂。
如果食堂被垃圾塞满了（内存泄漏），或者饭菜被吃光了（内存不足）。
- 关键点：
所有人（包括想新进来的员工）都没饭吃，整个公司瘫痪。
二、 StackOverflowError：单兵阵亡（Thread Down）
1. 发生原因
全称java.lang.StackOverflowError。
它发生在虚拟机栈。当线程请求的栈深度超过了 JVM 允许的最大深度（默认 1MB 左右，由-Xss控制）时抛出。
2. 经典业务场景：死递归
最常见的场景就是：没有出口的递归调用。
- 场景复现：
你写了一个“查询父子级分类”的方法，结果逻辑写歪了，A 调用 B，B 又调用 A。
// ❌ 错误代码示范public void recursiveCall() {// 忘记写终止条件，或者条件永远无法满足recursiveCall();}
3. 爆炸半径（重点！）
面试官问：JVM 会挂吗？
答：通常不会！
- 现象：
如果你在 Web 服务（如 Tomcat）的一个 HTTP 线程里触发了死递归。
- 当前线程
的栈空间瞬间被打爆，抛出
StackOverflowError。 - Tomcat 主线程池
捕获到这个
Error（注意，Tomcat 会捕获 Throwable），打印错误日志，并向前端返回 500 错误。 - 该线程结束销毁，栈空间释放。
- 结局：
那个倒霉的用户看到了报错。
- 但是！
隔壁线程的栈是空的，其他用户的请求依然可以正常处理。
- 结论：
这是一个线程级的灾难，不是进程级的。
三、 OutOfMemoryError：粮仓耗尽（System Down）
1. 发生原因
全称java.lang.OutOfMemoryError(OOM)。
绝大多数情况发生在堆内存 (Heap)。当 JVM 无法为新对象分配内存，且 GC 回收后依然不够时抛出。
2. 经典业务场景：大对象的一波流
- 场景复现：
运营搞活动，导出一个包含 100 万条记录的 Excel，开发人员直接把所有数据List<User>加载到了内存。
// ❌ 错误代码示范List<byte[]> list = new ArrayList<>();while (true) {// 疯狂占用堆内存list.add(new byte[1024 * 1024]);}
3. 爆炸半径（重点！）
面试官问：JVM 会挂吗？
答：虽然进程不一定立马消失，但系统已经实质性瘫痪了！
- 现象：
那个导出 Excel 的线程把堆内存 (Heap)占满了。
- GC 开始疯狂工作
（Stop The World），CPU 飙升 100%，试图回收垃圾，但回收不掉。
此时，正常的登录请求进来了，需要创建一个小小的
LoginDTO对象。- JVM 说：
“对不起，公共食堂没饭了。” ->正常请求也抛出 OOM！
- 更可怕的是：
甚至连后台的心跳线程、日志线程都申请不到内存。
- 结局：
整个应用进入“假死”状态，所有接口响应超时或报错。
通常我们会配置
-XX:+ExitOnOutOfMemoryError让 JVM 自动自杀重启，否则它就是个“植物人”。- 结论：
这是一个进程级的灾难。
四、 总结一张表（建议打印贴工位）
下次面试，直接把这张表甩在面试官面前：
维度 | StackOverflowError (SOE) | OutOfMemoryError (OOM) |
内存区域 | 虚拟机栈 (Stack) | 堆 (Heap) / 元空间 / 堆外 |
资源性质 | 线程私有(Thread Local) | 进程共享(Shared) |
触发原因 | 方法调用太深 (死递归) | 内存泄漏 或 巨型对象 |
JVM 状态 | 存活。仅当前线程挂掉。 | 瘫痪。全站不可用。 |
能否恢复 | 能。该线程释放后，其他线程无影响。 | 难。通常需要重启。 |
排查参数 |
(调整栈大小) |
/ (调整堆大小) |
五、 Fox 的“防杠”指南（进阶必看）
面试官可能会追问：“有没有特殊情况，StackOverflowError 也会导致 OOM？”
Fox 满分回答：
“有！但不是因为递归深度。
如果在创建线程时，无法申请到足够的栈内存（比如系统总内存耗尽，或者-Xss设置得太大导致每个线程都巨占内存），JVM 会抛出OutOfMemoryError: unable to create new native thread。
这时候，虽然是栈的问题，但表现出来的是 OOM，这属于操作系统级别的资源耗尽。”
写在最后
- StackOverflowError
就像是你卧室的垃圾桶满了，你扔不进去了，但不影响你爸妈在客厅看电视。
- OutOfMemoryError
就像是家里的冰箱空了，全家人（所有线程）都得饿死。
搞清楚“私有”和“共享”的区别，你就掌握了 JVM 事故排查的钥匙。
觉得讲得透彻的兄弟，点个赞，转发给那个以为 Error 就会宕机的同事！
