递归深度无固定值，由线程栈大小（-Xss）和每层栈帧开销共同决定；默认-Xss1m时空递归约8000–10000层，加局部对象后常降至2000层以内，调大-Xss虽可提升深度但会线性减少最大线程数。
递归深度不是固定数字，它由线程栈大小和每层调用实际开销共同决定。调大 -Xss 能提升可支持的递归层数，但会直接减少系统能创建的线程总数——这不是权衡，而是硬性制约。
怎么估算当前 -Xss 下的递归极限
默认 -Xss1m（64位 Linux 常见）时，一个空递归方法（无参数、无局部变量）大概能跑 8000–10000 层；但只要加两个对象引用和一个 int 局部变量，就可能掉到 2000 层以内。每层栈帧实际占用受以下因素影响：
- 方法参数类型：传
new byte[1024]比传String引用多占约 1KB 栈空间 - 局部变量数量与大小：大数组、嵌套对象初始化都会推高单帧体积
- JVM 是否启用压缩指针（
-XX:+UseCompressedOops）：默认开启，对栈帧有轻微压缩效果，但不可依赖 - 是否在调试模式下运行：断点、监控代理可能额外增加栈帧负担
调整 -Xss 对递归深度的实际影响
增大 -Xss 不是“修复”递归问题，而是把崩溃点往后挪。比如：
-
-Xss512k→ 空递归约 4000 层，含局部对象后可能仅剩 1000 层 -
-Xss1m→ 空递归约 9000 层，典型业务递归（如树遍历、JSON 解析）常卡在 1500–3000 层 -
-Xss2m→ 理论翻倍，但实际提升常不到 1.7 倍，因操作系统页对齐、JVM 内部结构开销非线性增长
注意：-Xss 设置的是上限，不是初始分配量。栈空间按需扩展，直到触顶才报错。
-Xss 变化如何牵动并发线程数
每个 Java 线程都独占一份 -Xss 规定的虚拟内存空间。假设宿主机可用虚拟内存为 1GB：
-
-Xss256k→ 最多约 4000 个线程 -
-Xss512k→ 最多约 2000 个线程 -
-Xss1m→ 最多约 1000 个线程 -
-Xss2m→ 最多约 500 个线程
超过该阈值，会抛出 OutOfMemoryError: unable to create new native thread，尤其在容器环境或 Linux 上受 /proc/sys/vm/max_map_count 限制更明显。
真正该优先做的排查动作
遇到 StackOverflowError，别急着改 -Xss。先确认是不是递归失控：
- 用
jstack抓线程快照，搜索重复出现的方法名——连续几百行同名方法基本就是递归没终止 - 检查所有递归入口：是否覆盖全部边界（比如
n == 0和n 都要处理） - 打印前几次调用参数，看是否单调收敛（如 10→9→8…→1→0→-1→-2）
- 能转成迭代的尽量转：用
Stack或队列手动维护状态，彻底摆脱栈深限制
只有在确认递归逻辑正确、深度合理（例如已知最多 800 层），且无法重构代码时，才考虑微调 -Xss。服务端应用推荐从 -Xss256k 或 -Xss512k 起步，压测验证稳定性。
