栈大小需匹配业务场景：过小引发stackoverflowerror，过大导致线程数受限和oomkilled；推荐微服务设256k、io密集型128k，配合压测与jstack验证。
栈空间大小直接影响方法调用深度、线程数量上限和内存使用效率。它不是越大越好，也不是越小越安全，关键在于匹配实际业务场景的调用特征和并发规模。
栈大小决定方法嵌套的最大深度
每个方法调用都会在栈中压入一个栈帧，保存局部变量、操作数栈、返回地址等信息。栈容量固定时，能容纳的栈帧总数就决定了递归或链式调用的最大层数。
- 栈太小（如128KB），浅层递归（几百层）就可能触发
StackOverflowError - 栈太大（如2MB），单次调用虽更“宽松”，但会快速耗尽线程可用内存
- 典型参考值：普通Web请求处理一般256KB–512KB足够；含深度反射或复杂表达式解析的场景可设为1MB
栈大小影响可创建的线程总数
物理内存总量固定，每个线程独占一份栈空间。栈越大，同等内存下能启动的线程越少。
- 设总堆外内存为4GB，-Xss1m → 理论最多约4000个线程
- 同环境下改用-Xss128k → 线程数可提升至约3.2万个
- 虚拟线程场景更敏感：1MB × 100万线程 = 1TB内存需求，实际不可行
不当设置会引发两类典型异常
栈配置错误不会静默失效，而是以明确异常暴露问题：
- StackOverflowError：栈空间耗尽，常见于无限递归、循环调用、或局部变量表过大（如大数组声明在方法内）
- OutOfMemoryError（unable to create new native thread）：系统无法为新线程分配栈内存，本质是操作系统级资源不足，常因-Xss设得过大且线程数激增所致
如何合理设置-Xss参数
没有通用最优值，需结合应用类型实测调整：
- 常规平台线程：推荐范围256K–1M，从512K起步，观察压测中是否出现栈溢出或线程创建失败
- 高并发I/O密集型（如Spring WebFlux + 虚拟线程）：建议64K–256K，配合
--enable-preview启用Loom特性 - 避免盲目调大：即使设为2M，深层递归仍会溢出，只是延后发生；反而压缩了线程池弹性空间
- 验证方式：用
jstack <pid></pid>查看线程栈使用率，或通过-XX:+PrintGCDetails观察GC日志中栈相关提示
