-Xss用于平衡线程数量与单个线程栈深度，不当配置会限制并发或引发StackOverflowError/OutOfMemoryError；它控制每线程栈空间，影响递归、AOP代理等场景，需结合jstack分析和实际调用链调整。
设置 -Xss 不是为了“堆出更多线程”，而是在线程数量与单个线程安全执行深度之间找平衡点。它不提升并发能力本身，但配置不当会直接限制并发上限或引发静默崩溃。
线程栈大小影响什么
每个 Java 线程启动时，JVM 为其分配一块独立的虚拟机栈空间，用于存放方法调用帧、局部变量、操作数栈等。这个空间由 -Xss 控制，单位必须明确（如 -Xss256k），不能省略或写错（-Xss256 kb 会启动失败）。
- 栈太小 → 深度递归、复杂 AOP 代理链、嵌套 Lambda 容易触发
StackOverflowError - 栈太大 → 同样内存下可创建线程数锐减，可能提前报
OutOfMemoryError: unable to create new native thread - 默认值因平台而异：HotSpot 64位 Linux 通常为 1MB，Windows 为 320KB，OpenJDK 17+ 部分构建已降至 512KB
怎么判断该调大还是调小
别靠猜，先看真实占用：
- 用
jstack抽样多个线程，观察最深栈帧数量（比如某次调用链达 80 层） - 结合调用逻辑估算：每层平均占约 1–2KB，预留 1.5 倍余量较稳妥
- 若应用基本无递归、用的是 Netty/Vert.x/WebFlux 等事件驱动模型，实测栈常低于 128KB，
-Xss256k足够 - 若大量使用 Spring AOP + MyBatis 动态代理 + 异常增强，栈帧易膨胀，
-Xss384k～512k更稳
典型场景下的推荐值
没有万能值，但有适配逻辑：
-
高密度线程服务（如轻量 API 网关、连接密集型网关）：优先保障线程数，设
-Xss128k或-Xss256k；若用 Project Loom 虚拟线程，Carrier Thread 可设-Xss128k，虚拟线程自身不受 -Xss 影响 -
含深度业务递归（如规则引擎、树形结构遍历、老版本 XML 解析）：观察 jstack 最大深度，设为
-Xss1m或-Xss2m，避免偶发溢出 -
容器化部署：检查
ulimit -s是否小于 -Xss，否则 JVM 启动即失败；同时注意 cgroup 内存限制，它比 -Xss 更容易成为线程创建瓶颈
容易被忽略的关键细节
-Xss 是 JVM 启动时锁定的参数，运行期不可修改，也不支持 JMX 动态调整。
- 它不参与 GC，不计入 -Xmx 统计，属于堆外内存
- 和 -XX:ThreadStackSize 冲突时，后者会覆盖前者，但该参数无文档保障，禁止用于生产
- 某些 JDK 版本（如 Oracle JDK 8u291 前）启用 G1GC 时，若 -Xss 小于 256k，G1 并发标记线程可能 StackOverflow
- 调小后不一定会立刻报错，可能只在特定异常分支、日志打印路径或多级 fallback 中才暴露
