线程栈大小直接决定并发上限，过大导致线程数锐减，过小引发栈溢出崩溃；需结合压测、jstack和容器ulimit精准调优，虚拟线程下-xss仍影响载体线程资源占用。

线程私有栈空间大小直接决定单个线程占用的虚拟内存，进而成为系统并发线程数的硬性天花板。它不提升性能本身，但配置失当会卡死并发能力——栈设太大，线程数断崖下跌；设太小，还没跑满就因栈溢出崩溃。

栈大小如何换算成并发上限

可用并发线程数 ≈（进程剩余虚拟内存）÷ 单线程栈大小。这个“剩余虚拟内存”不是总内存，而是扣除JVM堆（-Xmx）、元空间、直接内存、系统保留空间后的余量。

• 32位环境或受限容器中，进程总虚拟地址空间常仅2–3GB；若-Xss1m，约3000个线程即耗尽地址空间
• 64位系统虽地址空间极大，但实际受物理内存+swap、ulimit -v（虚拟内存限制）、RLIMIT_STACK共同约束
• Linux中每个线程栈由mmap分配，计入进程VSZ（虚拟内存大小），即使未用满也持续占位

默认8MB栈在高并发场景下的真实代价

很多Linux发行版默认线程栈为8MB，这在现代轻量服务中属于严重浪费。

• 1000个线程 × 8MB = 8GB虚拟内存——远超Web请求处理、RPC调用等典型任务所需
• 大量空闲栈页加剧TLB压力，拖慢上下文切换，尤其在CPU核心数多、线程频繁调度时
• 在1GB RAM容器中，可能因OOM killer直接终止JVM进程，错误日志却只显示“unable to create new native thread”

合理设置栈大小的关键操作

不能靠经验拍脑袋，必须结合实测与业务特征调整。

• Java用-Xss控制，单位必须明确：-Xss256k合法，-Xss256 kb会启动失败
• 先压测定位最小安全值：用递归函数或框架深度代理链（如Spring AOP + MyBatis嵌套）触发StackOverflowError，再加20%余量
• 观察真实使用量：通过jstack查看栈帧深度，或用perf record -e syscalls:sys_enter_clone + /proc/[pid]/maps分析实际映射页数
• 容器部署时同步设置ulimit -s（单位KB），避免JVM参数生效但OS层拦截

虚拟线程场景下的特殊注意点

Java 19+虚拟线程虽默认栈极小（几KB），但-Xss仍间接影响其载体线程的栈预留行为。

• 沿用平台线程的-Xss1m配置运行虚拟线程，会导致每个虚拟线程预占过大空间，引发GC压力飙升、吞吐下降超40%
• 虚拟线程适合I/O密集型任务，其栈按需增长，但深度同步计算仍需保障基础栈水位
• 建议搭配Thread.ofVirtual().unmount()或显式控制carrier线程池，避免-Xss误配放大资源开销