StackOverflowError本质是线程栈空间耗尽，不一定是无限递归——只要调用链总深度超-Xss限制（默认约1MB），JVM即抛出该异常，无论有意递归或无意嵌套调用。
StackOverflowError 到底是栈被填满了还是递归太深？
它本质是线程栈空间耗尽，不一定是“无限递归”——只要调用链总深度超过 -Xss 限制（默认通常 1MB），哪怕每层只压入几个字节也会触发。JVM 不区分“有意递归”和“无意嵌套调用”，只看当前栈帧数量和大小。
常见错误现象：Exception in thread "main" java.lang.StackOverflowError，没有堆栈行号或只有极短的重复片段（比如全是 at com.example.Calc.compute(Calc.java:12)）；有时甚至没完整堆栈，直接崩溃。
- 递归没写终止条件（最典型）
- getter/setter 互相调用：
getA()返回b.getA()，而b.getA()又调用a.getA() - 代理类、Lombok
@Data+ 循环引用时的toString()或equals() - Spring AOP 代理方法自调用（非接口代理）导致切面重复织入
怎么快速定位哪一层在死循环调用？
别靠肉眼扫日志。启动时加 JVM 参数 -XX:+PrintStackTraceOnCrash（Java 17+）或更通用的 -XX:+PrintGCDetails -XX:+PrintConcurrentLocks 配合 jstack <pid> 抓现场；开发阶段优先用 IDE 的「Drop Frame」+ 断点回溯。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在疑似递归入口加日志：
log.debug("compute({}) depth: {}", value, Thread.currentThread().getStackTrace().length); - 用
jstack -l <pid>查看线程栈，重点关注java.lang.Thread.getStackTrace后面连续出现的相同方法名 - 如果用的是 Lombok，临时删掉
@Data，手动写toString()并加 guard：if (seen.contains(this)) return "[Circular]";
改代码比调参数更可靠，但-Xss真能解决问题吗？
能缓解，但治标不治本。增大 -Xss（如设为 -Xss2m）只是把崩溃点往后推，可能从 8000 层撑到 12000 层，一旦数据稍复杂又爆。而且每个线程都吃更多内存，高并发下容易 OOM。
性能与兼容性影响：
-
-Xss是 per-thread 的，线程数多时总内存占用显著上升 - 某些容器（如 Quarkus native image）不支持动态调整栈大小
- Android Dalvik/ART 对栈控制更严格，
-Xss无效
真正该做的：把递归转成迭代，或用显式栈（Deque<Node>）模拟调用过程。例如树遍历，别写 visit(node.left); visit(node.right);，改用 while + stack.push()。
为什么有些递归不会报 StackOverflowError？
尾递归优化（Tail Call Optimization）在 Java 中默认不生效。哪怕你写成 return factorial(n-1, acc * n);，JVM 也不会复用栈帧——这是语言规范决定的，不是 JVM 实现问题。所以别信“只要最后是 return 就安全”这种说法。
容易被忽略的点：
- lambda 表达式里捕获外部递归变量，可能隐式延长栈帧生命周期
- 使用
ThreadLocal存储中间状态时，若清理不及时，会拖慢 GC，间接加剧栈压力 - 某些 JNI 调用（如 JNA）会在本地栈分配额外空间，进一步压缩 Java 栈可用深度
复杂点在于：同一个方法，在不同 JDK 版本、不同 CPU 架构（x86 vs aarch64）、甚至不同编译器优化级别（-O2 对 JIT 的影响）下，实际栈消耗可能差 10%～20%。上线前务必在目标环境压测。
