StackOverflowError本质是线程栈空间耗尽，非内存不足；由递归缺陷、隐式循环调用、调用链过载引发，需代码修复（迭代替代递归、切断循环引用）、架构收敛深度，并用jstack定位。
StackOverflowError 不是内存不足，而是线程栈被撑爆了——每次方法调用都会压一个栈帧，压到超出 JVM 分配的固定空间（默认约 1MB）就直接报错。它无法被 try-catch 捕获，属于 Error 级别，必须从代码结构或调用逻辑上修复。
递归写错：出口失效或深度失控
看似有 if 判断，但出口实际不生效，是最隐蔽的隐患。比如参数用 n-- 而非 n - 1，导致下层传入值不变；或初始值为负数，却只检查 n == 0，跳过所有终止分支。
- 检查所有递归函数：确认终止条件可到达、逻辑无歧义、参数每次调用都严格收敛
- 对已知大数据量场景（如树高可能超 2000 层），优先改用迭代+显式栈模拟 DFS/BFS
- 避免在 toString()、equals()、hashCode() 中隐含递归调用，尤其含双向引用的对象
对象图隐式循环：JSON、Lombok、AOP 自动触发
代码里没写递归，但框架行为会自动展开引用链。例如 User 持有 Dept，Dept 又反向持有 users 集合，Jackson 序列化时就会 User → dept → users → user → … 无限套娃。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- JSON 场景：用 @JsonIgnore、@JsonBackReference 或 @ToString(exclude = "xxx") 显式切断循环字段
- Lombok 场景：禁用自动生成 toString()，或用 @ToString(exclude = {"dept", "users"}) 精确排除
- AOP 场景：检查代理配置是否误匹配目标方法自身，导致 method → proxy → method 闭环
调用链结构性过载：框架封装层层叠加
一行业务逻辑背后可能是 Spark 的 map→flatMap→filter→map… 十几层嵌套，或是 MyBatis-Plus + LambdaQueryWrapper + 自定义拦截器 + 全局过滤器 + AOP 增强，单次请求压栈十几层。
立即学习“Java免费学习笔记（深入）”；
- 限制链式调用长度，复杂查询拆成多步执行，避免单条语句嵌套过深
- AOP 切点不用 execution(* *(..)) 这类宽泛表达式，精确到包名+方法签名
- 日志打印前做对象简化（如只打 ID、类型、size），避免触发 toString() 引发连锁展开
定位与验证：别靠猜，用 jstack 快速抓现场
生产环境出问题，第一反应不是加 -Xss，而是立即导出线程栈快照。重复出现的方法名就是突破口。
- 执行 jstack <pid> > stack.log，搜索高频堆栈行（如反复出现 com.xxx.User.toString）
- 本地复现时，在 IDE 中启用“Drop Frame”功能，逐层退出看哪一层开始异常重复
- 加 -XX:+PrintGCDetails 辅助排除是否混入堆内存问题（StackOverflowError 本身和堆无关）
