-xss参数需按业务特征合理设置：高并发场景推荐256k～512k以提升线程密度，深度计算场景建议1m～2m避免栈溢出，windows环境宜设为512k起步，异步框架推荐1m，project loom虚拟线程仅需128k。
-Xss 参数不能盲目调大，核心是匹配业务特征、控制风险、验证效果。它设的是每个线程的私有栈上限，不是越大越安全，也不是越小越高效——关键在“合理”。
先确认是不是真要调 -Xss
很多 StackOverflowError 其实和栈大小无关，而是代码问题：
- 递归方法没写对终止条件，或条件永远不成立
- 隐式递归：Lombok 的 @Data + 循环引用、Jackson 反序列化嵌套对象、AOP 切面层层代理
- 单个方法里声明了超大局部数组（如 byte[1024*1024]）或大量局部变量，撑爆当前栈帧
- 调用链过深（A→B→C→…→Z，上百层），但业务本不该这么设计
按场景选值，别套默认
不同业务对栈深度和线程数的要求差异很大：
- 高并发短链路场景（API 网关、HTTP 接入层）：-Xss256k～512k。省内存，支撑更多线程
- 深度计算型场景（规则引擎、表达式解析、树遍历）：-Xss1m～2m。避免中途压栈失败
- Windows 环境默认栈偏小（约 320KB），建议显式设为 -Xss512k 起步
- Netty/Vert.x/WebFlux 等异步框架：调用链深，推荐 -Xss1m
- Project Loom 虚拟线程：只影响 Carrier Thread，-Xss128k 即可；虚拟线程栈在堆中，不受 -Xss 约束
必须检查系统和容器限制
JVM 启得起来，不代表参数真生效：
- Linux 下运行 ulimit -s，确保软限制（单位 KB）≥ 你设的 -Xss 值，否则 JVM 启动直接失败
- Docker/K8s 中，总栈内存 = 线程数 × -Xss，不能接近容器 memory limit，否则线程创建会静默失败
- JDK 8u291 之前启用 G1GC 时，-Xss 小于 256k 可能导致 GC 线程自身栈溢出
调完一定要验证，不能只靠“设了就放心”
上线前和压测中重点看三件事：
- 用 jstack
查最深线程的调用栈层数，一般建议 ≤ 500 层（具体看业务逻辑复杂度） - 压测时观察 StackOverflowError 是否消失，同时盯紧 GC 频率、线程数是否异常飙升
- 生产环境加 -XX:+PrintGCDetails 和 -XX:+ShowMessageBoxOnError，便于快速捕获现场
