-xss参数直接控制线程栈大小，从而影响栈深度：值越大，支持递归或嵌套调用越深，但内存开销增加；值越小，单线程占用低，但易触发stackoverflowerror；-xx:threadstacksize功能等价但单位固定为kb；默认值依平台而定，如64位linux为1mb；需据高并发、深度递归或普通web等场景合理选值，并结合jstack、jstat等工具验证效果。
直接通过 -Xss 参数设置线程栈大小，就能控制栈深度——值越大，可容纳的栈帧越多，支持的递归或嵌套调用越深；值越小，单线程内存占用低，但容易触发 StackOverflowError。
核心参数：-Xss 和 -XX:ThreadStackSize
两者功能等价，只是写法和单位不同：
-
-Xss：推荐使用，单位支持
k（KB）、m（MB），例如-Xss512k、-Xss1m -
-XX:ThreadStackSize：单位固定为 KB，例如
-XX:ThreadStackSize=512等效于-Xss512k - 未配置时，HotSpot 默认值依平台而定：64位 Linux 通常为 1024KB（1MB），Windows 32位约 320KB，macOS 多为 512KB
- 可通过
java -XX:+PrintFlagsFinal -version | grep ThreadStackSize查看当前 JVM 实际默认值
怎么选合适的值？看业务场景
没有统一最优值，关键看调用链特征和并发压力：
-
高并发微服务（如网关、API服务）：推荐
-Xss256k ~ 512k。线程数常达数千，减小栈能显著提升可创建线程上限，避免OutOfMemoryError: unable to create new native thread -
深度递归或复杂解析（如规则引擎、编译器、表达式求值）：建议
-Xss1m ~ 2m。保障数百层以上调用不中断，尤其当逻辑无法改写为迭代时 -
普通 Web 应用（Spring Boot 主流业务）：
-Xss512k是较稳妥的平衡点，兼顾调用深度与内存效率
怎么验证调得对不对？
光设参数不够，得结合运行时表现判断：
- 出现
java.lang.StackOverflowError：说明栈太小。检查堆栈轨迹中最深的调用链，再结合jstack <pid></pid>观察线程栈帧数量 - 频繁创建/销毁线程失败，报
unable to create new native thread：可能是栈设太大，挤占了进程虚拟内存（尤其是 32 位环境或容器内存限制严时） - 用
jstat -gc <pid></pid>或监控工具观察线程数增长趋势，配合 GC 日志交叉分析内存分配压力
几个易忽略的关键细节
栈大小不是和调用层数简单换算的，实际受多种因素影响：
- 每个栈帧大小取决于局部变量数量、参数类型（
long/double占 2 个变量槽）、字节码复杂度 - JVM 版本、是否开启 JIT 优化、甚至方法内联行为，都会改变同一方法的栈帧开销
- 操作系统按页对齐分配（如 4KB 一页），实际分配空间可能略大于设定值
- 同一个应用中，不同线程栈大小一致，不能为某类线程单独设值
