stackoverflowerror是jvm运行时错误，因线程调用栈深度超限导致；常见于无终止条件的递归、隐式循环调用或tostring等方法中自引用；典型特征是堆栈跟踪大量重复行；解决需修复逻辑而非盲目调大-xss。
Java中堆栈过深异常，就是java.lang.StackOverflowError。它不是普通异常（Exception），而是Error的子类，属于JVM底层运行时错误，说明当前线程的调用栈已耗尽空间，无法再压入新的栈帧。
为什么栈会“过深”
每个Java线程都有独立的虚拟机栈，方法每调用一次，JVM就分配一个栈帧——存参数、局部变量、返回地址等。这些帧按调用顺序堆叠，形成“调用栈”。栈空间默认有限（通常1MB左右），一旦嵌套太深，就会溢出。
- 最常见的是递归没写退出条件，比如
void f() { f(); } - 递归有退出条件，但逻辑错误导致永远不触发，如
if (n == 0) return; else f(n); - 方法间隐式循环调用，比如A调B、B调C、C又调回A
- 重写了
toString()或equals()，内部又间接触发自身（如打印对象时调toString，而toString里又用了该对象）
怎么看是不是栈过深
抛错时堆栈跟踪（stack trace）里会出现大量重复、高度相似的行，例如：
at com.example.MyClass.process(MyClass.java:22)at com.example.MyClass.process(MyClass.java:22)
at com.example.MyClass.process(MyClass.java:22)
…（连续几百甚至上千行）
这种规律性重复是典型信号——不是某处报错，而是“一路压栈压爆了”。
立即学习“Java免费学习笔记（深入）”；
怎么解决才靠谱
- 先检查所有递归方法：确认有明确、可达的终止条件，且每次递归都在向该条件靠近（如
n-1而非n） - 对树/图遍历等场景，考虑加深度限制或改用显式栈+迭代（避免依赖JVM栈）
- 避免在
toString()、equals()、hashCode()中直接或间接引用自身结构 - 慎用
-Xss调大栈空间（如-Xss2m）——治标不治本，还可能掩盖真实逻辑缺陷
什么时候可以考虑调栈大小
仅当确认代码逻辑无误，但业务确实需要极深调用（如解析超长嵌套JSON、编译器AST遍历等），且已优化到极限时，才作为最后手段调整。日常开发中，99%的StackOverflowError都源于可修复的逻辑问题，而非栈太小。
基本上就这些。
