高并发下应避免递归调用，优先转为显式栈+迭代；严格限制递归深度并校验输入；谨慎调整-Xss参数；排查隐式递归陷阱；JDK21+可启用虚拟线程缓解问题。
高并发场景下，递归调用极易引发 StackOverflowError，但单纯靠调大虚拟机栈参数（-Xss）不仅治标不治本，还可能引发“无法创建新线程”等更严重问题。真正有效的优化，是把参数调整作为辅助手段，核心落在代码结构与执行模型的重构上。
优先将递归转为显式栈 + 迭代
这是最根本、最可靠的规避方式。它完全脱离 JVM 调用栈限制，改用堆内存管理执行上下文，天然适配高并发。
- 用
Deque<State>或Stack<State>模拟递归状态（如当前节点、深度、临时计算值） - 用 while 循环驱动处理，每次 pop 一个状态，处理后 push 新状态（如有子任务）
- 可轻松加入深度限制、超时控制、中断检查，提升健壮性
例如树遍历、表达式求值、嵌套 JSON 解析等场景，均可用此法安全替代深层递归。
严格限制递归深度并校验输入
即使保留递归结构，也必须设置硬性上限，防止恶意或异常数据触发失控调用。
- 在方法入口处增加深度参数，并在每次递归前判断：
if (depth > MAX_DEPTH) throw new IllegalArgumentException("Recursion too deep"); - 对用户输入的嵌套结构（如 XML/JSON 层级、正则表达式复杂度）做预检，拒绝超限请求
- 结合线程局部变量（
ThreadLocal<Integer>）跟踪当前线程递归深度，避免被代理/AOP 干扰
谨慎使用 -Xss 参数作为兜底补充
仅当确认是合法深度递归（如科学计算、固定规模解析）且无法重构时，才考虑微调 -Xss，并需同步评估线程容量影响。
- 先用
jstack -l <pid>抓取崩溃线程栈帧数，估算单次调用平均栈深；再结合预期并发线程数反推所需总栈内存 - 64 位 Linux/Windows 默认
-Xss1m，可尝试-Xss512k（减小）或-Xss1536k（略增），避免直接设为 2m+，尤其在线程池密集型服务中 - 若应用已迁移到 JDK 21+，优先启用虚拟线程（
Thread.ofVirtual()），其栈在堆中动态分配，不受-Xss约束，天然缓解该问题
排查并消除隐式递归陷阱
很多栈溢出并非来自显式 method() { method(); }，而是由框架机制引发的循环调用链。
- 检查
equals()/hashCode()实现是否意外触发自身字段的递归比较（如双向关联对象） - 审查 AOP 切面、Spring 代理、Jackson 序列化器等是否造成
A → B → A类型的调用闭环 - 禁用不必要的 toString() 递归打印（尤其在日志中），改用白名单字段格式化
