线程栈参数过小在超高并发下会引发大量线程集体栈溢出，导致StackOverflowError集中爆发、服务假死和线程池饥饿；需结合jstack分析真实栈深、识别框架隐式调用（如AOP代理、Jackson循环序列化）、验证vsz内存占用与系统ulimit限制，并通过压测确定合理-Xss值（如768k）配合有界线程池使用。

线程栈参数配置过小，在超高并发场景下容易引发大量物理线程同时耗尽各自栈空间，从而集中爆发 StackOverflowError。这类问题不是单个递归导致的“慢溢出”，而是成百上千线程在短时间压满默认栈（如1MB）后集体崩溃，常伴随服务假死、HTTP连接超时、线程池饥饿等连锁现象。排查需聚焦“线程行为+栈配置+并发压力”三者交叉点。

看真实线程栈深度，别只信-Xss默认值

不能一上来就加 -Xss2m。先确认是不是真缺栈空间：

• 用 jstack -l <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。