JVM堆栈溢出监测原理

来自玩Android网站上的一个提问： wanandroid.com/wenda/show/…

当我们递归调用Java方法时，很可能会出现StackOverflowError，我们会认为此时栈内存溢出了，那么这个栈内存溢出虚拟机是如何检测的呢？

是累加分配的内存与栈大小进行比较，还是有更好的方式呢？

下面是一种回答：

不是靠“累加分配大小做比较”，而是靠“访问受保护栈页面触发异常 + JVM 内部栈检查”来检测的。

分两层来看：操作系统层和 JVM 层（以 HotSpot 为例）。

1. OS 层面：通过“保护页 + 页面异常”感知栈满

线程栈本质是 OS 提供的一块连续虚拟内存区域，JVM 只是使用它。

典型做法（不同 OS 实现略有差异）：

1. 每个线程启动时 OS 会为其保留一块栈空间（如 1M、2M），其中一部分是真正可用的内存。

2. 在栈的“尽头”会预留一小段“保护页（guard page）”：

   1. 这块内存被标为不可访问；
   2. 一旦程序继续向下生长，访问到这块区域，就会触发页面访问异常（如 segmentation fault / access violation）。

在 HotSpot 中，每次方法调用、局部变量分配时，都会通过所谓的 stack banging 机制在即将申请的栈空间中访问特定地址，以确保一旦越界就立刻触发 OS 的异常，而不是“悄悄越界”。

这一步就保证了：栈真的用到边界时，OS 一定会抛异常出来。

2. JVM 层面：把“异常”转换为 StackOverflowError

JVM 收到来自 OS 的栈溢出信号时，它知道是当前线程栈用完了，然后：

1. 通过 HotSpot 的异常处理逻辑，将该异常转换为 **Java 层的 ****StackOverflowError**；
2. 在线程当前栈上构造一个异常对象并抛出（这本身也需要一点栈空间，所以 JVM 通常会预留一小段专门用于抛出异常的栈区域）。

这里有两种情况：

• 如果是Java 代码正常递归调用，一般就会抛出 StackOverflowError；
• 如果是 JNI / native 代码乱写栈、越界访问，有时候 JVM 来不及转换，直接就进程崩溃，打印 fatal error。

3. 为什么不是“累加分配大小 vs 栈大小”的简单比较？

从设计和实现上，简单做“累加计数”有一些问题：

1. 精确计算成本高每一帧的真实大小并不都是 JVM 完全可控的，涉及：

• JIT 编译后生成的机器代码具体栈帧布局；
• 调用 C/C++ runtime / 本地方法时的额外栈消耗；
• 各个平台 ABI、对齐方式等差异。

2. 无法覆盖所有情况即使 JVM 在建帧时做了 剩余栈空间 >= 预计需要空间？ 的检查，native 代码中还可能再消耗一些栈，此时 JVM 并不知道。

3. OS 本身已经提供了更可靠的栈溢出检测机制操作系统比 JVM 更清楚“栈的真实边界”，一旦页面访问越界，它能最准确、最及时地通知进程。

所以实际实现是：

• 主检测方式：依赖操作系统的Guard Page（保护页）与 Page Fault（缺页异常）
• 辅助：JVM 在生成代码时通过 stack banging 确保不会“跨页直接越界”
• 有些 JVM 实现会在每次建新帧前做一些**“剩余栈估算检查”**，用于提前抛 StackOverflowError，减少真正触发 page fault 的次数，但核心仍是 guard page。

4. HotSpot 中常见栈相关机制（简要）

以 HotSpot 为例，它一般会把线程栈分成几段逻辑区域：

• 正常栈区：用户代码正常用；
• 黄色页（yellow zone）：首次触发访问时，JVM 捕获并抛出 StackOverflowError；
• 红色页（red zone）：黄色页处理失败或继续下探时，视为致命错误，通常直接崩溃，避免破坏堆或其他内存。

启动 JVM 时通过 -Xss 指定每个线程的栈大小，影响的是这块区域的总规模。
但具体的检测点、抛异常的逻辑，不靠简单“加减计数”，而是靠 guard page + OS 异常 + JVM 处理。