调大-xss仅延缓栈溢出，不能根治；应先确认是否真需调栈（查堆栈日志有无重复调用），再据线程模型设合理值（如高并发用256k～512k，计算型用1m～2m），并同步将递归转迭代、加深度限制、用流式解析等优化代码。
调大 -Xss 参数能延缓栈溢出，但不能根治问题——它只是给缺陷代码争取时间。真正有效的做法是先确认是否真需调栈，再结合业务特征设合理值，并同步优化递归逻辑。
先判断是不是真要调栈
看到 StackOverflowError，别急着改参数。先看堆栈日志里有没有大量重复方法调用（比如连续几十行都是 at com.xxx.Parser.parse(...)）。如果有，大概率是递归失控或隐式循环调用（如 AOP 代理嵌套、Jackson 循环引用）。这类问题靠调栈解决不了，必须修复代码。
- 检查递归方法是否漏写终止条件，或终止条件永远不满足
- 确认是否存在意外的深层嵌套（如模板渲染中层层 include）
- 留意单个方法里是否声明了超大局部变量（如
byte[1024*1024]），这会直接撑爆单帧
怎么设一个合理的 -Xss 值
不是越大越好，关键看线程模型和调用特征：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 高并发服务（如 Spring MVC Web 应用）：线程数多，建议
-Xss256k～-Xss512k，省内存、保线程容量 - 计算密集型单线程任务（如规则引擎、表达式解析）：允许更深调用，可设
-Xss1m～-Xss2m - Windows 环境默认栈偏小（约 320KB），建议显式设为
-Xss512k起步 - 总栈内存 = 线程数 ×
-Xss，比如 200 线程 × 2MB = 400MB，得确保不挤占堆空间引发 OOM
调完必须验证和监控
参数生效不等于问题消失：
- 用
jstack -l <pid></pid>查看异常线程的栈深度，确认最深调用是否已收敛（例如 ≤800 层） - 压测时观察
StackOverflowError是否消失，同时盯住线程数是否异常飙升 - 生产环境建议加
-XX:+ShowMessageBoxOnError，出错时弹窗留现场；配合-XX:+PrintGCDetails排查是否误触发 GC
比调参更可靠的替代方案
遇到深层递归，优先考虑降栈而非扩栈：
- 把递归转成显式栈 + 循环，把调用状态从线程栈挪到堆内存，完全规避 JVM 栈限制
- 对 JSON/XML 解析等场景，换用流式解析器（如 Jackson 的
JsonParser），避免树形结构全加载 - 所有递归入口加深度控制：方法签名带
int depth参数，入口处校验if (depth > 1000) throw new IllegalStateException() - 避免在递归体中重复创建大对象，把大数组、大字符串等移到堆上分配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
