-xss参数决定虚拟机栈深度，空间越大调用层数越多，过小易触发stackoverflowerror，过大则导致outofmemoryerror；需按平台线程/虚拟线程角色及场景（如网关设256k、规则引擎设1m）分治配置。
虚拟机栈深度不是固定数字，而是由 -Xss 参数设定的每个线程可用栈空间决定的——空间越大，能容纳的调用层数越多；空间越小，递归或嵌套稍深就容易触发 StackOverflowError。
栈深度与-Xss的直接关系
栈深度本质上是“在给定栈空间下最多能压入多少个栈帧”。而每个栈帧大小取决于：方法参数数量、局部变量个数与类型、字节码复杂度等。因此：
- -Xss=256k 时，典型递归深度约在 1.2 万～1.8 万层（视方法体大小浮动）
- -Xss=1m 时，同样逻辑可能支持到 4 万～6 万层
- 实测显示：-Xss 翻倍，递归深度大致提升 1.9～2.1 倍，并非严格线性，但趋势明显
不同线程类型对-Xss的响应差异
-Xss 只作用于平台线程（Platform Thread），对虚拟线程（Virtual Thread）基本无效：
- 平台线程：栈内存由操作系统分配，-Xss 直接控制其初始和最大栈大小
- 虚拟线程：栈帧默认在堆中动态分配，初始极小（几KB），按需增长；-Xss 不影响它，但过大的 -Xss 可能间接拖慢载体线程调度
- 误将 -Xss=1m 用于高并发虚拟线程场景，会导致 JVM 预留大量未使用的本地内存，引发 GC 压力上升、吞吐下降超 40%
设置不当的两类典型后果
看似只是调一个参数，实际会导向两个相反方向的故障：
- 设得太小：轻量服务（如网关）可能正常，但一旦接入深度规则引擎或旧有递归工具类，立刻报 StackOverflowError；日志里只看到异常堆栈，难定位是配置问题还是代码缺陷
-
设得太大：单机启动 5000 个线程时，-Xss=1m 就占用 5GB 栈内存（不计入堆），极易触发
OutOfMemoryError: unable to create new native thread，尤其在容器内存受限环境下
生产环境推荐配置策略
不靠经验拍脑袋，而是按线程角色分治：
- 微服务 API 层 / 网关 / 异步任务消费者：-Xss=256k 或 384k（兼顾线程密度与常见调用链）
- 规则引擎、编译器后端、数学计算模块：-Xss=1m～1.5m，并配合压测验证最深路径
- 启用虚拟线程（Java 19+）：统一设为 -Xss=128k，且必须避免在虚拟线程中写深度递归或大局部变量方法
- 所有场景都建议加 JVM 参数：
-XX:MaxJavaStackTraceDepth=1024，限制异常堆栈长度，降低日志开销
