Spark中Scala代码调用resultSaver.saveResult偶发StackOverflow问题

核心排查方向 #

1. 定位错误堆栈的递归调用链 #

StackOverflowError本质是无限递归或过深的方法调用栈，偶发情况大概率是特定数据触发。先从错误堆栈里找重复出现的方法序列：

• 检查saveResult内部处理数据时（比如解析嵌套结构、递归遍历对象）是否缺少终止条件；
• 排查序列化/反序列化过程中，第三方库（比如Jackson、Jedis）对特殊数据（循环引用对象、超深嵌套JSON）的递归处理是否溢出。

2. 重新梳理JedisPool的使用逻辑 #

即使标记了@transient，仍可能存在隐式引用问题：

• 确认Executor端JedisPool的初始化逻辑，是否在saveResult中意外引用了Driver端的非序列化对象，导致序列化时出现循环引用；
• 检查Jedis操作的线程安全：Spark Executor是多线程环境，若JedisPool的配置或使用方式不当（比如重复获取连接未释放、线程内递归调用Jedis命令），可能触发栈溢出。

3. 排查输入数据的特殊性 #

偶发问题几乎都和数据强相关，重点统计报错批次的数据集特征：

• 是否存在超深嵌套结构（比如嵌套层级超过JVM栈默认深度）；
• 是否包含循环引用的对象（比如实体类互相引用）；
• 是否有异常大的单条数据，导致处理时栈内存被耗尽。

4. 验证Spark资源配置的合理性 #

• 增大Executor栈大小后，确认配置是否生效：检查Spark提交命令中是否添加了--conf spark.executor.extraJavaOptions="-Xss4m"（可根据需求调整栈大小）；
• 若spark.executor.cores设置过大，会导致每个Core分配的栈资源被稀释，可尝试降低并行度，观察问题是否缓解；
• 排查Shuffle阶段的中间数据大小，若Shuffle数据量过大，可能导致处理时栈压力激增。

关键补充信息 #

请提供以下内容以进一步定位：

• resultSaver类的完整实现代码，尤其是saveResult方法的核心逻辑；
• 错误堆栈的完整内容，重点标注重复出现的方法调用链。

内容的提问来源于stack exchange，提问作者chucklai