StackOverflowError不是-Xss越大越好，增大仅延迟崩溃且易引发OOM；应优先排查递归失控、隐式递归及循环依赖，并通过jstack和全栈日志定位问题。
StackOverflowError到底是不是-Xss调得越大越好
不是。增大-Xss只是把栈溢出的临界点往后推，不解决根本问题，反而可能掩盖递归失控或循环依赖等真实缺陷，还容易在多线程场景下快速耗尽内存。
典型错误现象：java.lang.StackOverflowError反复出现，但调大-Xss后只延迟几秒就又崩；或者单线程正常，一开100个线程就OOM（堆外内存）。
-
-Xss是每个线程的**独占栈空间**，设为2m意味着1000个线程至少占用2GB虚拟内存（即使大部分未使用） - HotSpot默认值因JDK版本和平台而异：JDK 8 Linux x64 默认
1024k，JDK 17+ 默认1m，Windows通常更小 - 真正该优先检查的是递归深度是否可控、是否有隐式递归（如
equals()/toString()里误调自身）
怎么定位哪段递归/调用链触发了StackOverflowError
靠日志和线程快照，别猜。JVM抛出StackOverflowError时，默认会打印异常栈，但往往被截断——必须加参数让它吐全。
- 启动时加上
-XX:MaxJavaStackTraceDepth=10000（默认-1表示不限，但某些JDK版本需显式设大值） - 发生错误后立刻用
jstack <pid></pid>抓线程快照，重点看java.lang.Thread.State: RUNNABLE且栈帧高度重复的线程 - 常见陷阱：框架代理类（如CGLIB、Spring AOP）会让栈帧看起来像“自己调自己”，实际是拦截器无限重入
- 如果栈里反复出现
at java.util.Objects.equals或at com.example.User.toString，大概率是equals()或toString()里没防循环引用
递归改迭代时要注意哪些边界和性能坑
不是简单套个while循环就行。手动维护栈结构时，顺序、状态保存、终止条件都容易出错，尤其涉及树遍历或回溯场景。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 原递归中局部变量要转成栈元素字段，比如
int depth需作为StackFrame对象的成员，否则逻辑错乱 - DFS类递归改迭代后，若用
LinkedList模拟栈，addLast()/removeLast()比push()/pop()语义更清晰，避免误用removeFirst()变成BFS - 大量短生命周期对象（如每层新建一个
StackFrame）可能增加GC压力，可考虑对象池复用，但前提是确认这是瓶颈（先测再优化） - 别为了“去递归”硬拆——如果递归深度稳定
为什么有些递归用@TailRec注解也没用
Java语言本身不支持尾递归优化，@TailRec是Lombok或Scala的玩意，JVM字节码层面根本没这个机制。所谓“优化”只是编译期报错提醒你写错了，并不会生成循环指令。
- 哪怕你写了形如
return factorial(n-1, acc * n)，Javac仍生成普通方法调用字节码，栈帧照常增长 - 想真做尾递归，要么用Scala（运行在JVM上但编译器重写为循环），要么用Trampoline模式（返回
Supplier<t></t>层层套，用循环展开），但后者有额外对象分配开销 - 最现实的做法：接受Java无尾调用的事实，对已知深递归路径，明确限制最大深度并抛业务异常（如
throw new IllegalArgumentException("depth exceeds 1000")），比让JVM崩掉更可控
真正难的从来不是调哪个参数，而是判断“这段逻辑到底该不该递归”——比如JSON序列化时遇到循环引用，与其死磕递归终止条件，不如直接配置ObjectMapper的SerializationFeature.FAIL_ON_SELF_REFERENCES或用@JsonIdentityInfo。
