StackOverflowError是栈空间耗尽而非内存溢出；它由线程栈帧超限引发，与堆内存和GC无关，需通过-Xss调优，根本解决需修复递归终止条件或隐式调用环。
StackOverflowError 是栈空间耗尽，不是内存溢出
Java 中 StackOverflowError 和 OutOfMemoryError 完全不同：前者发生在 JVM 线程栈上，后者才涉及堆内存。每个线程启动时分配固定大小的栈（默认通常 1MB 左右），函数调用、局部变量、方法参数都压入栈帧；一旦调用链太深（尤其是递归没终止），栈帧持续堆积，超出上限就直接抛 StackOverflowError。
- 它和 GC 无关，调大堆内存（
-Xmx）完全无效 - 真正起作用的是
-Xss参数，比如-Xss2m可把单线程栈设为 2MB - 但治标不治本——栈空间再大也扛不住无限递归
最常见诱因：递归缺少边界或边界失效
看似有 if 判断的递归，实际可能永远进不了终止分支。典型例子是参数未正确收敛、整数溢出导致条件恒真、或浮点数精度问题使比较失效。
public static int factorial(int n) {
if (n == 0) return 1; // 表面看有终止
return n * factorial(n - 1); // 但若传入负数，n 永远不会等于 0
}- 调用
factorial(-1)→factorial(-2)→ … 直到栈满 - 类似地，
binarySearch里left > right没写对，或递归调用传了错误的mid值，也会跳过终止条件 - 注意：JVM 不会主动检测“重复调用相同参数”，只管栈深度
容易被忽略的非显式递归场景
不是只有自己写 foo() { foo(); } 才算递归。以下情况同样会层层压栈：
-
toString()方法里意外调用了自身（比如打印对象时触发toString，而该方法又调用了System.out.println(this)） - 重写了
equals()或hashCode()，内部又间接引用了当前对象的其他方法，形成隐式调用环 - 使用 Lombok 的
@Data时，若字段类型存在循环引用（如 A 持有 B，B 持有 A），生成的toString()默认会无限展开 - Spring AOP 代理 + 递归方法：代理对象调用自身方法可能绕回代理逻辑，造成额外一层调用
如何定位和验证是不是 StackOverflowError
错误堆栈输出非常关键：看最顶端几行是否呈现高度重复的相同方法名，且深度在千级以上（比如连续几百行都是 com.example.Calc.compute(...)）。
立即学习“Java免费学习笔记（深入）”；
- 用
jstack <pid>抓线程快照，搜索java.lang.StackOverflowError，观察调用链是否规律性重复 - 加 JVM 参数
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps无用——GC 日志里不会出现栈溢出信息 - IDE 调试时别盲目设断点：如果递归很深，断点可能卡死或根本触发不到终止前的位置；优先改代码加日志，比如在入口打
System.out.println("depth=" + depth) - 注意：某些 JVM 版本（如 JDK 8u20+）会对尾递归做有限优化，但 Java 语言本身不支持尾调用消除，不能依赖
递归本身没问题，问题永远出在控制流没走到出口。栈空间是硬限制，没法靠配置兜底；真正要盯紧的是每次递归调用后，状态是否朝着终止条件可靠推进。
