如何解决Spark的java.lang.OutOfMemoryError及GC overhead超限问题？

核心问题分析 #

你广播3GB的table1后出现堆内存不足和GC开销超限错误，核心诱因可能是：

• 广播数据在内存中实际占用远大于原始3GB（列式存储转Row对象、序列化开销、元数据等导致数据膨胀）
• Executor堆内存分配不足以同时容纳广播变量、任务运行的中间数据
• GC配置不合理，导致频繁GC且无法有效回收内存

具体解决步骤 #

1. 确认广播变量的实际内存占用 #

通过Spark UI的Storage标签查看广播变量的真实大小：

• 如果实际内存占用远超3GB（比如5-8GB），先优化广播表：
  • 仅保留Join必需的关联键和业务字段，过滤冗余列
  • 确保广播表采用Parquet/ORC等列式存储格式，读取时自动启用列裁剪

2. 调整Executor内存与核心数配置 #

当前--executor-memory 18g的堆内存余量不足，无法同时承载广播变量和分区任务：

• 增大Executor堆内存：改为--executor-memory 24g或--executor-memory 32g
• 减少Executor核心数：将--executor-cores 4调整为--executor-cores 2，让每个任务分配到更多堆内存，降低GC压力
• 扩容堆外内存：把spark.executor.memoryOverhead从2g改为4g，避免堆外内存不足间接挤占堆内存空间

3. 优化广播与GC相关配置 #

• 强制手动广播：代码中显式调用broadcast(table1)，确保Spark优先采用广播Join逻辑，避免自动广播规则失效
• 延长广播超时：添加--conf spark.sql.broadcastTimeout=600（单位：秒），防止广播变量传输超时引发异常
• 更换GC收集器并调优：修改spark.executor.extraJavaOptions，用G1GC优化大内存堆的GC性能：

  --conf "spark.executor.extraJavaOptions=-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35 -XX:MaxDirectMemorySize=2048m"
  

  G1GC能更高效处理大内存场景，减少GC停顿和资源开销

4. 调整Shuffle分区数 #

当前spark.sql.shuffle.partitions=6000过大，导致任务数量过多、每个分区数据量过小，加剧GC频率：

• 按每个分区128MB计算合理值：120GB的table2需要120*1024/128=960个分区，设置--conf spark.sql.shuffle.partitions=960
• 分区数建议与spark.dynamicAllocation.maxExecutors * executor-cores匹配，确保每个Executor的核心能均匀处理分区

5. 排查额外内存占用点 #

• 清理代码中不必要的cache()/persist()缓存，及时释放无用数据集
• 检查UDF或自定义逻辑是否持有大对象，避免内存泄漏

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