线程栈参数过小在超高并发下会引发大量线程集体栈溢出，导致stackoverflowerror集中爆发、服务假死和线程池饥饿；需结合jstack分析真实栈深、识别框架隐式调用（如aop代理、jackson循环序列化）、验证vsz内存占用与系统ulimit限制，并通过压测确定合理-xss值（如768k）配合有界线程池使用。
线程栈参数配置过小，在超高并发场景下容易引发大量物理线程同时耗尽各自栈空间，从而集中爆发 StackOverflowError。这类问题不是单个递归导致的“慢溢出”，而是成百上千线程在短时间压满默认栈（如1MB）后集体崩溃，常伴随服务假死、HTTP连接超时、线程池饥饿等连锁现象。排查需聚焦“线程行为+栈配置+并发压力”三者交叉点。
看真实线程栈深度，别只信-Xss默认值
不能一上来就加 -Xss2m。先确认是不是真缺栈空间：
- 用
jstack -l <pid></pid>抓多个正常运行中的线程栈，统计平均栈帧数（比如多数线程栈深在80–120层）； - 再抓出错时刻的线程栈（或从日志里复制一段 StackOverflowError 的堆栈），看是否普遍卡在200–300层甚至更高；
- 如果出问题的线程栈深仅比正常线程高30%～50%，大概率是代码调用链本身不合理，而非栈太小。
查线程创建源头，识别隐式栈消耗大户
超高并发下，真正吃栈的未必是业务递归，而是框架或中间件的隐式调用：
- Spring AOP代理嵌套：比如多层 @Transactional + @Cacheable + 自定义注解切面，每次代理都增加一层调用；
- JSON序列化循环引用：Jackson 在处理未加
@JsonIgnore或@JsonManagedReference的双向关联对象时，会反复进入 getter 方法； - 模板引擎深度渲染：Thymeleaf 或 FreeMarker 中 include 层级过深、自定义方言递归解析表达式；
- 日志上下文传播：MDC 在异步线程间透传时，若配合某些链路追踪 SDK（如 SkyWalking 插件），可能触发意外递归赋值。
验线程数与栈内存总量是否越界
每个线程独占一份栈空间。假设应用启了 500 个线程，-Xss1m 就固定占用 500MB 栈内存——这部分不进堆，但吃系统虚拟内存和物理内存页表项：
- 用
ps -eo pid,vsz,rss,comm | grep java查看 Java 进程总虚拟内存（vsz）是否异常膨胀； - 检查系统级限制：
ulimit -s（Linux 线程栈软限制）是否低于 JVM 设置的-Xss，会导致线程创建失败； - 观察 GC 日志里是否频繁出现 “No space to allocate stack” 类提示（部分 JDK 版本会输出）；
- 对比线程池实际活跃线程数与
Runtime.getRuntime().availableProcessors()，若长期维持在 2×CPU 数以上且持续增长，说明线程失控，栈资源只是表象。
调参要配套压测验证，避免负向优化
盲目增大 -Xss 可能引发新问题：
- 线程数不变时，
-Xss2m比-Xss1m多占一倍栈内存，可能触发 OOM Killer 杀进程； - 线程池若用无界队列（如
new LinkedBlockingQueue()），线程数可能随请求暴增，-Xss加大会加速内存耗尽； - 正确做法：先用
-Xss512k压测，观察是否仍溢出；若稳定，再结合ThreadPoolExecutor设置有界队列 + 拒绝策略，把线程数控在合理范围（如 ≤200）； - 最终推荐组合：
-Xss768k+ 核心线程数≤50 + 最大线程数≤150 + 队列容量≤200 + CallerRunsPolicy。
