-Xss直接决定单线程虚拟内存占用，理论最大线程数≈可用虚拟内存÷-Xss；设太大则线程数锐减，设太小易致StackOverflowError，需结合压测与调用深度实测确定安全值。
-Xss 直接决定单个线程占用的虚拟内存大小，而系统能创建的并发线程数，本质上是“可用虚拟内存总量 ÷ 单线程栈大小”的向下取整结果。它不提升并发能力，但配置不当会成为硬性瓶颈——栈设太大，线程数锐减；设太小，又可能在深度调用路径上静默崩溃。
为什么-Xss会卡死线程数上限
每个 Java 线程背后是一个操作系统级线程（pthread），JVM 为其申请独立的栈空间，这块内存来自进程的用户态虚拟地址空间，和堆（-Xmx）互不隶属。当总栈内存需求超过剩余虚拟内存时，OS 拒绝分配，抛出 OutOfMemoryError: unable to create new native thread——这不是 JVM 堆溢出，而是系统资源耗尽。
- 假设宿主机为 64 位 Linux，JVM 可用虚拟内存约 1GB（扣除堆、元空间、系统保留等）
- -Xss1m → 理论最多约 1000 个线程
- -Xss512k → 理论最多约 2000 个线程
- -Xss256k → 理论最多约 4000 个线程
- -Xss128k → 理论最多约 8000 个线程
实际线程数还受哪些系统级限制
-Xss只是其中一环，真正上线前必须检查三重卡点：
- ulimit -s：当前 shell 进程允许的单线程栈软限。若设为 8MB（默认常见值），而你传 -Xss10m，JVM 启动直接失败，日志只显示 “Could not create the Java Virtual Machine.”
- ulimit -u：用户级最大进程/线程数。比如设为 4096，哪怕内存充足，也到不了 5000 线程
- /proc/sys/kernel/threads-max：系统全局线程上限。容器中常被 cgroup 内存限制压制，比 -Xss 更早触发失败
怎么定一个安全又高效的-Xss值
别拍脑袋，靠实测+逻辑估算：
- 用
jstack <pid>抽样 10–20 个活跃线程，看最深调用链有多少层（比如某次 HTTP 请求处理达 72 层） - 每层栈帧平均占 1–2KB，乘以 1.5 倍余量 → 若最大深度 80 层，建议栈 ≥ 120–240KB
- Spring Boot + Tomcat 场景：实测常见占用 150–300KB，
-Xss384k是较稳起点 - Netty/Vert.x/WebFlux 或 Project Loom 虚拟线程：栈压得极低，
-Xss128k或-Xss256k即可，设大纯属浪费
调小-Xss不是万能解药
降低单线程开销确实能腾出更多线程名额，但风险同步存在：
- 日志框架（如 Logback 的异步追加器）、JSON 序列化（Jackson 深嵌套对象）、正则回溯、AOP 多层代理——这些路径容易多压几层栈，-Xss256k 在正常请求下没事，但在异常分支里突然 StackOverflow
- 某些 JDK 版本（如 Oracle JDK 8u291 前）启用 G1GC 时，若 -Xss < 256k，G1 并发标记线程自身就会溢出
- 调小后需全链路压测：覆盖登录、查询、提交、异步回调、CompletableFuture 链等主路径，每次下调后至少稳定运行 10 分钟
