Java应用启动时设置-Xss的实际效果
改-Xss不是“加了就并发更高”，它只控制每个线程的**栈内存上限**，不直接影响线程数上限。真正卡线程数的是堆外内存总量（-Xmx + -Xss × 线程数 + 元空间等），以及操作系统级限制（如ulimit -s、ulimit -n）。
常见错误现象：java.lang.OutOfMemoryError: unable to create new native thread，很多人第一反应调大-Xss，结果更早崩——因为单个线程吃更多内存，总线程数反而下降。
- 默认值因JVM版本和平台而异：HotSpot 64位Linux通常为1MB，Windows为320KB，OpenJDK 17+部分构建可能降到512KB
- 若应用大量使用递归、深度嵌套Lambda、或框架（如某些老版本Spring AOP代理链）导致栈帧膨胀，才真需要调高
-Xss - 微服务里跑Netty/Vert.x这类基于事件循环的框架，线程栈实际占用往往不到128KB，
-Xss256k足够，盲目设1M纯属浪费
-Xss参数写法与生效优先级
必须作为JVM启动参数传入，不能在代码里动态改，也不支持运行时JMX修改。写错格式直接导致JVM启动失败，报错类似：Unrecognized VM option '-Xss512'（缺单位）或Invalid initial heap size: -Xss512m（单位过大）。
- 单位必须明确：支持
k、K、m、M，不接受kb、mb或空格，例如-Xss256k合法，-Xss256 kb非法 - 不能和
-Xms/-Xmx混用同一数值单位逻辑：它不参与GC，也不计入堆内存统计 - 如果同时用
-XX:ThreadStackSize（HotSpot内部参数），它会覆盖-Xss，但该参数无文档保障，生产环境禁用
高并发场景下-Xss的典型取值策略
没有“标准值”，取决于你的线程模型和实际栈深。压测前先用jstack抽样看真实占用，比拍脑袋设值靠谱得多。
立即学习“Java免费学习笔记（深入）”；
- 普通Spring Boot Web应用（Tomcat线程池）：线程栈实测常在150–300KB之间，
-Xss384k是较稳的起点 - 使用Project Loom虚拟线程（
-XX:+EnablePreview -Djdk.virtualThreadScheduler.parallelism=1）：虚拟线程栈默认极小（~2KB），-Xss对它们无效，只影响Carrier Thread，此时应优先调小（如-Xss128k）以腾出更多系统资源 - JNI调用频繁或自定义类加载器深层委托链：需观察
jstack输出中最大帧深度，预留1.5倍余量，避免StackOverflowError
容易被忽略的兼容性与副作用
-Xss调得太小，不一定立刻报错，但可能在特定路径上静默失败——比如某个异常处理分支多压一层栈，就刚好越界。
- 某些JDK版本（如Oracle JDK 8u291之前）在启用
-XX:+UseG1GC时，若-Xss小于256k，可能导致G1并发标记线程触发StackOverflowError - Docker容器内运行时，
ulimit -s若设得比-Xss还小，JVM启动直接拒绝，日志里只有Could not create the Java Virtual Machine.，没具体原因 - Log4j2异步日志（
AsyncLogger）在高吞吐下可能产生额外栈帧，和-Xss低配叠加，引发偶发崩溃，这种问题在线下压测不易复现
线程栈大小从来不是孤立参数，它和你用的JDK版本、GC算法、容器限制、甚至glibc版本都咬合在一起。调它之前，先确认jstack -l <pid> | grep 'java.lang.Thread.State' | wc -l</pid>看到的线程数是否已逼近系统上限——否则，90%的情况，你该调的其实是线程池大小或连接复用策略。
