StackOverflowError是Error而非Exception，因其表示JVM栈空间彻底耗尽，无法构造异常对象或执行catch/finally；常见于无限递归及隐式递归（如toString、equals中自调用、Lombok循环引用、AOP代理绕过等），需通过jstack或打点定位最早重复方法，修复应优先改递归为迭代、设终止条件、排除循环引用，而非盲目调大-Xss。
为什么StackOverflowError不是Exception而是Error
因为StackOverflowError表示JVM栈空间彻底耗尽，已无法安全执行任何异常处理逻辑——连构造Exception对象所需的栈帧都分配不出。JVM直接终止当前线程，不触发catch或finally。你写try-catch(Error e)理论上能捕获，但捕获后几乎无法恢复，强行继续可能引发InternalError或静默崩溃。
最常见诱因：无限递归与隐式递归
显式递归容易发现，但以下情况更易被忽略：
-
equals()、hashCode()、toString()中意外调用自身（比如在toString()里打印this，而该类重写了toString()又调用了toString()） - getter/setter循环引用：A类的
getB()返回B，B的getA()又返回A，且两者都在toString()中调用对方 - Lombok的
@Data或@ToString未排除循环引用字段，生成的toString()自动展开整个对象图 - Spring AOP代理对象在方法内调用
this.method()，绕过代理导致原生方法重复进入切面逻辑
验证方式：启动时加-XX:MaxJavaStackTraceDepth=1000（默认-1为不限），再看堆栈是否呈现高度重复的固定方法序列。
如何定位和修复递归源头
不要只看报错栈顶，要找「最早开始重复」的位置。用jstack 抓线程快照，搜索重复出现的方法名；或在可疑方法入口加System.out.println(Thread.currentThread().getStackTrace()[2].getMethodName())临时打点（注意避免日志本身触发递归）。
立即学习“Java免费学习笔记（深入）”；
修复原则：
- 递归必须有明确、可到达的终止条件，且每次递归必须向该条件推进（比如
n减小而非增大） - 对象结构含循环引用时，手动实现
toString()并跳过反向引用字段，或用@ToString(exclude = "b") - 避免在
equals()中调用可能触发计算或代理的方法，优先用Objects.equals(a, b)做字段级比较 - 将深度递归改为迭代+显式栈（
Deque），尤其处理树/图遍历时
public ListtraverseDFS(Node root) { List result = new ArrayList<>(); Deque stack = new ArrayDeque<>(); stack.push(root); while (!stack.isEmpty()) { Node node = stack.pop(); result.add(node); // 逆序压入子节点，保证左→右顺序 for (int i = node.children.size() - 1; i >= 0; i--) { stack.push(node.children.get(i)); } } return result; }
-Xss参数不是万能解药
增大线程栈大小（如-Xss2m）只能推迟问题，不能根除。它会让溢出发生得更晚，掩盖真实逻辑缺陷，还可能因单线程占用更多内存，导致应用在高并发下更快OOM。64位JVM默认-Xss1m已足够应对绝大多数合理递归；若业务真需要深栈（如解析超长嵌套JSON），应优先检查是否可改用流式解析（JsonParser）或分段处理。
真正关键的是：栈深度是否与输入规模成线性关系？如果是，说明算法本身存在隐患——比如递归求斐波那契数列时间复杂度O(2^n)，栈深O(n)，但输入n=10000时栈早炸了，而迭代解法栈深恒为O(1)。
