测栈溢出是为了预判架构级风险，通过缩小-xss、埋点栈深、arthas trace和jstack定位隐式递归链，用失败归因图拆解spi/aop/泛化调用等叠加效应，最终落地编译期扫描与栈深度熔断的防御设计。
直接讲清楚“为什么测”“怎么逼出问题”“测出什么能证明你懂系统本质”，比堆技术名词更关键。总监级最关心你是否具备架构级风险预判能力，而非工具使用熟练度。
聚焦真实故障场景，而不是压数字
大厂总监见惯了 QPS 过万的报告，但很少有人说清：栈溢出在什么链路组合下真正发生？不是“加到 5000 并发就崩”，而是“当服务 A 同步调用 B，B 又通过 Dubbo 泛化调用 C，C 内部做三层动态代理+反射+SPI 加载时，第 17 层递归触发 JVM 栈超限”。要定位到具体调用路径、类加载上下文、字节码增强行为。
- 用 Arthas 的 trace -j 跟到底层方法入口，确认递归深度和调用链长度
- 用 jstack -l
抓线程快照，过滤 WAITING/BLOCKED 状态中栈帧数 > 800 的线程 - 在关键代理类（如 MyBatis MapperProxy、Feign ReflectiveFeign）里加 Thread.currentThread().getStackTrace().length 日志埋点
主动暴露 JVM 和框架的隐式栈消耗
很多崩溃不来自业务递归，而来自框架自动补全的“隐形栈”。比如 Spring AOP 的 CGLIB 回调、Logback 异步 Appender 的 MDC 传递、甚至 Jackson 反序列化深层嵌套对象时的 JsonParser 递归解析。
- 用 -Xss256k 主动缩小栈空间，加速暴露问题（注意：仅限测试环境）
- 禁用 Log4j2 的 AsyncLoggerConfig，改用同步模式，排除异步上下文传播带来的额外栈开销
- 对 JSON 字段加 @JsonDepth(5) 限制反序列化深度，配合测试 payload 构造深层嵌套结构
用“失败归因图”代替测试报告
总监不看 TPS 曲线，要看你能不能把一次栈溢出，拆解成可归责的技术决策链：是 SPI 扩展点设计未限制加载层级？是 RPC 调用透传了过多 MDC key 导致 ThreadLocal 堆积？还是泛化调用未做参数扁平化导致反射调用栈爆炸？
- 画一张横向时间轴图：从请求进入网关 → 经过 3 层 Filter → 进入 Controller → 调用 Service → 触发 4 次远程调用 → 其中 1 次触发动态代理 → 最终在第 6 层 invoke() 中抛出 StackOverflowError
- 每一段标注栈帧估算数量（如：SpringMVC HandlerExecutionChain.addInterceptor ≈ +12 帧）
- 标出可优化锚点：如将泛化调用改为静态 stub、将 MDC key 白名单化、给 SPI 扩展加 @Order 和最大加载数限制
收尾落在“防御性设计”而非“问题修复”
总监想听的是你怎么让这类问题“不再需要靠压测发现”。比如在 CI 阶段加入字节码扫描规则：禁止非 final 类的 public 方法递归调用；在 RPC SDK 中默认开启栈深度监控开关；在内部规范里定义“跨服务调用链深度 ≤ 3，含代理/反射的本地调用栈 ≤ 200 帧”。
- 把栈深度检查做成 Maven 插件，在编译期扫描 @Service/@Component 类中的递归调用模式
- 在公司 RPC 框架中内置栈水位告警：单次请求执行过程中，若 currentThread.getStackTrace().length > 300，自动打点并上报
- 推动中间件团队在 Sentinel 或自研网关中增加“调用链栈深度熔断”策略，而非只看 QPS/RT
不复杂但容易忽略：真正的深度栈压力，往往藏在“大家都觉得安全”的组合动作里——一次看似普通的接口调用，叠加了 AOP、泛化、SPI、MDC、JSON 反序列化五个机制，每个加 50 帧，就轻松突破默认 1024 栈限制。你能提前画出这张叠加图，就已经赢过 90% 的候选人。
