使用spark.sql.autoBroadcastJoinThreshold时Spark Driver内存未释放问题

针对你遇到的循环内执行5表内连接后Driver内存持续增长最终OOM的问题，结合你给出的配置和报错信息，我整理了以下排查和解决思路：

1. 先明确核心问题：Driver内存泄漏而非广播阈值问题 #

你调整spark.sql.autoBroadcastJoinThreshold没有效果，是因为这个参数控制的是Executor端自动广播小表的大小，和Driver端的内存增长没有直接关联。你的报错WARN TaskMemoryManager: Failed to allocate a page虽然看起来是Executor的内存告警，但你提到Driver内存持续增长，说明根源大概率是Driver端的查询计划、元数据或临时对象堆积导致的内存泄漏。

2. 针对性解决方法 #

（1）清理循环内的缓存与元数据

Spark Driver会保存每个查询的执行计划、缓存表的元数据等信息，循环次数多了这些对象会堆积无法及时被GC回收：

• 每次循环结束后，除了取消表的持久化，还要主动调用spark.catalog.clearCache()来清理所有缓存的表和查询计划
• 取消持久化时使用同步清理：table.unpersist(true)（true表示等待缓存块完全清理完成后再继续，避免残留内存占用）

（2）优化持久化策略

你现在在循环开始时持久化所有表、结束时取消，这对那张200MB的大表完全没必要——因为它的内容不会随循环变化，应该把它的持久化移到循环外部，只做一次持久化，循环内直接使用即可，减少不必要的内存申请和释放操作。

（3）强制广播小表，降低Shuffle压力

虽然广播阈值不影响Driver内存，但强制广播小表可以减少Join时的Shuffle操作，间接缓解整体内存压力：

import org.apache.spark.sql.functions.broadcast

// 在Join时显式指定广播所有小表
val resultDF = bigTable
  .join(broadcast(smallTable1), "join_key")
  .join(broadcast(smallTable2), "join_key")
  .join(broadcast(smallTable3), "join_key")
  .join(broadcast(smallTable4), "join_key")

这样能确保小表被广播到Executor节点，避免不必要的Shuffle数据传输。

（4）促进Driver端的垃圾回收

循环内生成的DataFrame/Dataset对象如果没有被及时释放，会持续占用Driver内存：

• 每次循环结束后，显式将查询生成的DataFrame对象置为null，帮助JVM识别可回收对象
• 调整Driver的GC参数，让垃圾回收更积极，比如在提交Spark任务时添加：

  --driver-java-options "-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails"
  

  最后一个参数可以打印GC日志，帮助你确认是否是GC不及时导致的内存堆积。

（5）检查循环内的隐式数据拉取

如果你的查询中存在collect()、take()等会把数据拉到Driver端的操作，一定要检查是否有大量数据被拉取——这会直接撑爆Driver内存。如果必须拉取数据，用limit()限制数据量，或者改为在Executor端处理。

3. 验证步骤 #

建议你先把大表的持久化移到循环外，加上spark.catalog.clearCache()和同步取消持久化，再运行循环，观察Driver内存是否还持续增长。如果问题依然存在，打开GC日志分析内存回收情况，定位未被回收的对象类型。

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