栈溢出源于线程栈大小与业务调用深度不匹配：高并发网关中，每个线程独占固定栈空间，而多层代理、序列化、AOP嵌套、异步回调等导致调用链过深，超出-Xss限制，引发集群性StackOverflowError；解决需优先收缩调用深度而非盲目增大栈。
栈空间配置过小在高并发分布式网关中引发栈溢出，核心在于线程栈资源与业务调用深度不匹配——每个请求线程都独占一份固定大小的栈，而网关类服务天然存在多层代理、序列化、规则匹配、TLS握手等深度调用链，一旦单线程栈不足以容纳最深路径，就会直接崩溃。
高并发场景放大栈压力
分布式网关常启用数百至数千个线程处理并发连接。若 JVM 线程栈设为默认 -Xss1m，而某条请求路径（如：Spring Cloud Gateway + Reactor Netty + Jackson 反序列化 + 自定义 Filter 链）产生 800+ 层调用帧，单个栈就超限。此时不是“偶尔溢出”，而是高并发下大量线程几乎同步触发 StackOverflowError，表现为集群性 500 错误或进程直接退出。
隐式递归与框架嵌套是关键推手
- JSON 序列化循环引用：Jackson 默认开启 `@JsonManagedReference`/`@JsonBackReference`，但配置遗漏时会陷入无限属性展开
- Spring AOP 代理叠加：多个 `@Aspect` 对同一方法织入，导致调用链呈指数级增长（如 Auth → RateLimit → Trace → Retry → fallback）
- 异步回调栈累积：WebFlux 中 Mono.flatMap 嵌套过深，虽不显式递归，但 Reactor 的栈内联（stack inline）机制仍会撑满栈空间
栈大小与连接数存在反向约束关系
网关通常需维持长连接（如 WebSocket、gRPC 流），每个连接绑定一个线程或虚拟线程。若总连接数达 10k，且每线程栈为 1MB，则仅栈内存就占用 10GB —— 这既不可持续，也易触发 OS 级 OOM Killer。因此不能无脑增大 -Xss，而应优先收缩调用深度：
- 禁用 Jackson 循环检测外的深度反射：设置
MapperFeature.USE_GETTERS_AS_SETTERS为 false - 将嵌套 Filter 改为扁平链式执行，避免层层 try-catch 包裹
- 对 gRPC 或 HTTP/2 请求启用流控限深，例如限制 header 解析层级 ≤ 10
验证与定位要抓真实栈顶
别只看异常日志里的“at … at … at …”重复行。用 jstack -l 抓全量线程快照，过滤出 栈帧数量最多 的线程（非报错线程），它往往暴露了最深路径。再结合 async-profiler -e stack 采样，确认热点是否集中在某个序列化器或路由解析器上——这才是根源，不是栈本身小，而是它被不合理地填满了。
