synchronized 本身不会导致栈溢出，但与无终止条件的递归（直接或间接）结合时，因锁重入允许而持续压栈，最终触发 StackOverflowError；应避免递归与同步组合，优先用迭代、原子类或状态机替代。
synchronized 本身不会直接导致栈溢出，因为它不增加调用深度；但若在 synchronized 方法/块中**递归调用自身或间接触发深度嵌套调用**，就可能引发 stackoverflowerror。关键风险点在于：锁重入 + 无终止条件的递归，而非 synchronized 本身。
避免递归与 synchronized 的危险组合
Java 中 synchronized 支持可重入（同一个线程多次获取同一把锁合法），但这不意味着可以放任递归。一旦递归未设边界，每层调用都压栈，锁重入只是“恰好能过”，并不能缓解栈空间消耗。
- 禁止在 synchronized 方法内直接或间接调用自身（如 A → B → A 场景）
- 检查所有被 synchronized 包裹的逻辑是否隐含循环依赖：比如监听器回调、事件发布、AOP 代理方法再进入同一 bean 的同步方法
- 特别注意 Jackson 序列化、Lombok @Data、Spring 循环依赖注入等场景——它们可能在 getter/setter 或 toString() 中意外触发同步块内的递归访问
用显式深度控制替代无界递归
若业务逻辑确需递归且必须同步（极少见），应在入口处强制限制调用层级：
- 传入 depth 参数，每次递归 +1，到达阈值（如 50 层）立即抛异常或降级返回
- 避免使用静态计数器（多线程下不可靠），改用 ThreadLocal<Integer> 记录当前线程递归深度
- 示例：synchronized(this) { if (depth > MAX_DEPTH) throw new StackOverflowPreventException(); ... recursiveCall(data, depth + 1); }
优先重构为非递归+并发安全结构
绝大多数需要“同步+重复处理”的场景，其实更适合用迭代+无锁工具替代：
- 计数类逻辑：用 AtomicInteger 替代 synchronized ++，彻底消除锁和递归双重开销
- 批量任务拆分：将“递归遍历树”改为 BFS/DFS 迭代 + 队列，临界资源用 ConcurrentHashMap 分段保护
- 状态流转类操作：改用状态机 + CAS 更新，避免在同步块里反复调用自身方法驱动状态
监控与兜底配置
即使代码已优化，仍需防范异常路径触发深层调用：
立即学习“Java免费学习笔记（深入）”；
- 上线后开启 JVM 参数 -XX:+PrintGCDetails -XX:+ShowCodeDetailsInExceptionMessages，让 StackOverflowError 带出完整调用链
- 用 jstack 定期采样，grep “java.lang.Thread.State: RUNNABLE” 后连续出现同一方法名超过 200 行，即为高危信号
- 通过 -Xss2m 适度增大线程栈（默认 1MB），仅为缓冲手段，不能替代代码修复
