Java栈溢出本质是线程调用栈空间耗尽，抛出StackOverflowError；典型场景包括无限/过深递归、单方法大量局部变量、过长调用链及线程过多导致总栈超限。
Java 程序运行时 JVM 栈内存溢出，本质是线程的调用栈空间被耗尽，JVM 无法为新方法调用分配栈帧，于是抛出 java.lang.StackOverflowError（注意：不是 OutOfMemoryError）。它和堆内存溢出不同，不涉及垃圾回收，而是线程执行上下文的“深度”或“宽度”超限。
栈溢出的典型触发场景
无限或过深递归调用
每次递归都会压入一个新栈帧。若缺少终止条件、终止逻辑错误，或递归深度远超默认栈容量（如默认-Xss1m下约支持 1000–3000 层普通方法调用），就会快速撑爆栈。
例如：斐波那契递归未加缓存、树遍历未判空节点、toString() 或 equals() 中意外触发自身调用。单方法中定义大量局部变量或大数组
栈帧包含局部变量表、操作数栈、动态链接等。如果一个方法里声明了数百个基本类型变量、多个大对象引用，或直接在栈上分配超大数组（如int[] a = new int[1024 * 1024]—— 实际仍分配在堆，但局部变量表和引用本身占栈空间），会显著增大单个栈帧大小，降低可嵌套深度。方法调用链过长（非递归）
A → B → C → D → … → Z，共几十甚至上百层连续调用，尤其在框架代理、AOP、反射调用链中容易出现。虽无循环，但总栈帧数超过线程栈上限，同样触发溢出。线程数量过多，总栈空间超限
每个线程独占一份栈内存（由-Xss设置）。若创建数千线程（如未用线程池、误用new Thread()处理每个请求），即使单个栈不大，整体虚拟内存也可能耗尽，JVM 在尝试创建新线程时抛出OutOfMemoryError: unable to create new native thread—— 这属于本地方法栈/系统资源耗尽，常被广义归为栈相关溢出。
如何确认是栈溢出
- 异常类型明确为
StackOverflowError - 堆栈跟踪（stack trace）中出现高度重复的方法名（如连续几十行
at com.example.Xxx.method(Xxx.java:xx)） - 错误日志末尾通常显示
Exception in thread "main" java.lang.StackOverflowError，不带Java heap space等堆提示
关键应对方式
-
优先检查代码逻辑
- 查找无终止条件的递归、toString()/hashCode()/equals() 中的隐式自调用
- 审查长调用链，考虑提取中间步骤、改用迭代或异步拆分
- 避免在方法内堆砌大量局部变量；大对象引用及时置 null（虽不影响栈，但有助 GC）
必要时调整线程栈大小
使用 JVM 参数-Xss增大单线程栈空间，例如-Xss2m。但这是权宜之计：栈变大可能掩盖设计缺陷，且会减少可并发线程数。控制线程总量
用ThreadPoolExecutor替代无节制new Thread()；设置合理核心/最大线程数与队列策略，防止线程爆炸。辅助定位
启用-XX:+PrintGCDetails和-XX:+PrintGCDateStamps虽主要用于堆，但结合线程 dump（jstack <pid></pid>）可观察各线程当前调用深度；对可疑方法添加日志或断点，验证调用次数是否符合预期。
不复杂但容易忽略
