StackOverflowError是JVM因栈帧总数×单帧大小超过线程栈总容量而强制抛出的错误，主因是无限/过深递归或方法嵌套，而非逻辑错误；-Xss调参治标不治本，易引发OOM或仅延迟崩溃，应优先重构代码。
StackOverflowError 是栈空间被耗尽的直接信号
它不是代码逻辑错误，而是 JVM 拒绝继续压栈的“硬性拦截”——当线程调用栈深度超过当前分配的栈容量时，JVM 就会抛出 java.lang.StackOverflowError。常见于递归没写终止条件、递归过深、或方法嵌套太长，但根本原因永远是：**栈帧数量 × 单个栈帧大小 > 当前线程栈总容量**。
为什么加 -Xss 不一定解决问题
增大线程栈（如 -Xss2m）看似立竿见影，但容易掩盖真实问题，还可能引发新风险：
- 单个线程栈从默认 1MB 增到 2MB，若应用创建 1000 个线程，仅栈内存就多占 1GB，可能触发
OutOfMemoryError: unable to create new native thread - 栈变大后，无限递归只是“晚一点崩溃”，而不是不崩溃；
recursiveMethod()调用 1 万次失败，改成 2 万次仍会失败 - 不同平台默认值差异大：
-Xss在 64 位 Linux 通常是 1MB，Windows 可能是 320KB，Mac 是 512KB——硬编码参数可能导致跨环境失效
递归深度的实际限制怎么算
没有固定“最多多少层”，它取决于三件事：当前 -Xss 值、每个栈帧占用空间、JVM 自身开销。一个典型 factorial(int n) 方法，每层栈帧约占用 200–400 字节（含参数、返回地址、局部变量表）。按默认 -Xss1m 粗略估算，安全递归深度通常在 5000–8000 层之间；一旦局部变量里有大数组（如 byte[] b = new byte[1024]），单帧就吃掉几 KB，深度立刻砍掉一个数量级。
验证方式很简单：
public class DepthTest {
static int depth = 0;
public static void recurse() {
depth++;
recurse(); // 不设终止，让它自己崩
}
public static void main(String[] args) {
try { recurse(); }
catch (StackOverflowError e) {
System.out.println("Max depth: " + depth); // 实际打印值就是你的临界点
}
}
}真正该做的：优先重构，再考虑调参
绝大多数生产环境的 StackOverflowError 都不该靠调 -Xss 解决。重点检查以下几类代码：
-
toString()、equals()、hashCode()中意外触发自身调用（比如 A.toString() 里用了 B.toString()，而 B.toString() 又反向引用了 A） - JSON 序列化/反序列化时循环引用未配置
@JsonManagedReference或@JsonIgnore - 使用 Lombok 的
@Data且类字段存在双向关联（如User和Order互相持有） - 本可用迭代替代的递归，比如树遍历、文件夹扫描、表达式求值——改用显式栈（
Deque<Node>）或队列，完全规避栈深度问题
如果必须保留递归，至少加深度防护：
public static int factorial(int n, int maxDepth) {
if (n <= 1) return 1;
if (maxDepth <= 0) throw new IllegalArgumentException("Recursion too deep");
return n * factorial(n - 1, maxDepth - 1);
}真正难处理的是那些“看起来不递归，实则隐式递归”的场景——比如框架回调链、AOP 切面嵌套、自定义 ClassLoader 加载逻辑。这类问题光看堆栈很难定位，得结合 jstack 抓现场线程快照，再逐帧比对重复模式。
