大数据：Spark 作业频繁 OOM？内存管理模型解析与 GC 调优技巧

一、OOM 的真实画像：三类故障与一条主线

在生产集群里，“Spark OOM”这个说法其实覆盖了至少三类完全不同的故障。第一类是 JVM 堆内 OOM，典型日志是 java.lang.OutOfMemoryError: Java heap space，往往发生在 shuffle 读端聚合、大宽表 join 或 collect 到 Driver 的场景。第二类是 堆外/本地内存 OOM，日志形如 OutOfMemoryError: Direct buffer memory 或容器被 cgroup 直接 kill（exit code 137），这类问题在启用堆外内存和向量化读之后明显增多。第三类是 GC overhead limit exceeded，它并非内存真的耗尽，而是 JVM 判定回收效率过低而主动抛错，本质是 GC 反馈环失衡。

这三类故障的排查入口完全不同，但笔者认为它们共享同一条分析主线：内存预算是否被正确切分、对象生命周期是否被正确估计、GC 反馈是否被正确观测。预算决定“够不够”，生命周期决定“什么时候该释放”，GC 反馈决定“释放得动不动”。任何一次 OOM 都可以沿这条线回溯到某个环节的估计偏差。Apache Spark 官方调优文档（Tuning Guide）也明确把内存管理列为独立章节，并强调序列化格式与 GC 调优的耦合关系^[1]。

本文评述：很多团队一遇 OOM 就加 Executor 内存，短期有效但常掩盖真实问题——预算没算清、对象没瘦身、GC 没观测，加内存只是把雪崩推迟到下一个更大的数据分区。真正稳的做法是先定位故障类别，再沿主线核算。

1.1 一个常见的误判：Driver OOM 与 Executor OOM 混淆

Driver 端 OOM 多由 collect()、toPandas()、广播变量过大或 AQE 收集分区统计信息引起。Executor 端 OOM 则集中在 shuffle、join、聚合与缓存。两者的调优手段几乎不重叠：前者要减少回传数据量或改用分布式写出，后者才涉及内存池与 GC。把两者混为一谈，是排查效率低下的首要原因。Databricks 的工程博客在多篇内存调优文章中都强调先区分 Driver 与 Executor 的故障域^[2]。

二、统一内存管理模型：池化、驱逐与预算边界

自 Spark 1.6 起，Unified Memory Management 取代了早期的静态内存划分，把 Executor 堆内内存划分为 Reserved（保留）、User Memory（用户内存） 与 Spark Memory（统一内存） 三块。其中 Spark Memory 又由 Execution 与 Storage 两个子池共享，默认各占 50%，但可以互相借用：当 Execution 池空闲时 Storage 可以占用，反之亦然。这一设计的核心思想是“按需借用、压力驱逐”，而不是硬性隔离。

表 1：Executor 堆内内存分区（依据 Apache Spark 官方 Tuning Guide 与源码 UnifiedMemoryManager 整理）^[1][3]

关键参数是 spark.memory.fraction（默认 0.6）与 spark.memory.storageFraction（默认 0.5）。前者决定 Spark Memory 占（heap − reserved）的比例，后者决定 Storage 在 Spark Memory 中的初始份额。注意：storageFraction 只是“初始份额”，不是硬隔离——Execution 池在需要时可以驱逐 Storage 中低于该份额的缓存块。

2.1 驱逐与 spill：两种不同的“释放”

Storage 池的释放是驱逐（eviction）：把缓存块从内存移除，下次用到时重新计算或重读。Execution 池的释放是溢出（spill）：把中间结果写到磁盘，后续再读回。二者语义不同，代价也不同。驱逐的代价是重算，spill 的代价是磁盘 IO 与序列化。很多 OOM 的根因不是内存不足，而是 spill 之后读回的数据再次撑爆 Execution 池，形成“spill—读回—再 spill”的抖动。笔者认为，观察 Spark UI 中 Spill (memory) 与 Spill (disk) 的比值，是判断 Execution 池是否长期过载的最直接信号。

2.2 一个容易被忽略的边界：User Memory 的失控

User Memory 不受 Spark 内存管理器管辖，UDF 里创建的临时集合、字符串拼接、正则编译缓存都落在这里。当 UDF 处理大对象（如解析超大 JSON、加载外部模型）时，User Memory 会悄悄膨胀，挤压 Spark Memory 的可用空间，最终表现为“明明 heap 很大却还是 OOM”。这类问题的排查不能只看 Spark UI，必须结合 JVM 堆直方图（jmap -histo 或 jcmd GC.class_histogram）定位对象来源。

三、Tungsten 与堆外内存：对象去哪了

Tungsten 项目是 Spark 2.x 之后性能提升的核心引擎，它做了三件事：用二进制行格式（UnsafeRow）替代 JVM 对象、用代码生成（Whole-Stage Code Generation）减少虚函数调用、用堆外内存（Off-heap）降低 GC 压力。理解这三件事，才能理解为什么“同样的数据量，换一种写法内存占用差一个数量级”。

3.1 UnsafeRow：把对象拍平成字节

一个 Java 对象在堆上的开销包括对象头（12–16 字节）、字段对齐填充、引用指针。以一条含 10 个字段的行、每字段平均 8 字节为例，对象化表示的实际占用可能是裸数据的 2–4 倍（模拟估算，基于 JVM 对象布局规则，非实测）。UnsafeRow 把字段按固定偏移量编码进连续字节数组，消除了对象头与指针，同时让序列化变成“内存拷贝”而非“反射遍历”。Apache Spark 的 Tungsten 设计文档与相关论文对此有系统描述^[4][5]。

本文评述：UnsafeRow 的收益不只是省内存，更重要的是让“内存占用可预测”。对象化表示下，你很难估算一个 DataFrame 分区占多少堆；二进制表示下，字节数就是字节数。可预测性本身就是调优的前提。

3.2 堆外内存：GC 的“避风港”与新的风险

开启 spark.memory.offHeap.enabled=true 并设置 spark.memory.offHeap.size 后，Execution 与 Storage 池可以使用堆外内存。堆外内存不受 GC 管理，因此能显著降低 Full GC 频率；但它也带来两个新问题：一是容器内存核算必须把堆外算进去，否则会被 cgroup OOM kill；二是堆外泄漏排查更困难，需要 NativeMemoryTracking 或 pmap 辅助。Netty 的 direct buffer 与 Spark 的 Unsafe 分配器共享同一片本地内存，二者叠加时尤其要留足余量。

表 2：内存相关核心参数（依据 Spark Configuration 官方文档）^[6]

四、GC 反馈闭环：为什么越 GC 越慢

GC 与内存之间不是单向关系，而是一个反馈环。内存压力大 → 对象晋升快 → 老年代快速填满 → Full GC 频繁 → 应用线程停顿 → 任务处理变慢 → 同一批数据在内存中停留更久 → 内存压力更大。这个环一旦形成，加内存只能暂时打断它，不能消除它。要打断它，必须从“减少对象分配速率”和“降低对象存活时间”两端同时下手。

4.1 先选对收集器

Spark 官方推荐 G1 作为默认收集器（JDK 9+ 默认即 G1），并在 Tuning Guide 中给出了 G1 的调优思路^[1]。G1 的优势是可预测停顿模型与分区回收，适合大堆（数十 GB）。对于超大堆（>64 GB）且停顿敏感的场景，ZGC 与 Shenandoah 也值得评估——它们把停顿压到毫秒级，代价是更高的 CPU 与内存开销。需要提醒的是，收集器选择必须与 JDK 版本匹配，且不能与堆外内存策略冲突。

表 3：收集器选型参考（综合 Oracle/OpenJDK 官方文档与 Spark Tuning Guide，停顿为公开资料的量级描述，非本环境实测）^[1][7]

4.2 打开 GC 日志，让反馈可见

没有 GC 日志的调优都是猜。JDK 9+ 推荐统一日志：-Xlog:gc*,gc+heap=info,gc+age=trace:file=/var/log/spark/gc.log:time,uptime,level,tags:filecount=5,filesize=50m。重点看三个指标：Young GC 频率与晋升速率、Full GC 次数与耗时、Humongous 对象分配（G1 下大于 region 一半的对象）。如果 Young GC 后老年代持续上涨且 Full GC 回收有限，说明存在长生命周期对象或泄漏；如果 Humongous 分配频繁，说明单条记录过大，应考虑拆分或改用堆外。

# 常用 GC 诊断命令（示例）
jcmd <pid> GC.heap_info          # 堆分区使用情况
jcmd <pid> GC.class_histogram    # 对象直方图，定位大对象来源
jstat -gcutil <pid> 1000 20      # 每秒采样，观察各区利用率
jcmd <pid> VM.native_memory summary  # 堆外内存追踪（需 -XX:NativeMemoryTracking=summary）

本文评述：GC 日志的价值在于把“感觉慢”变成“哪一段慢”。笔者建议把 GC 日志纳入 Spark 作业的标准输出物，与 Spark UI 的 Stage 指标并列归档，这样 OOM 复盘时才有时间对齐的现场。

五、Executor 内存配比：一份可核算的预算表

Spark 的 spark.executor.memory 只是 JVM 堆，容器总内存还要加上 spark.executor.memoryOverhead（默认 max(384 MB, 0.1 × executor memory)）、堆外内存、以及 JVM 元空间与线程栈。YARN/K8s 的容器限额必须覆盖这些总和，否则会被外部 kill。下面给出一份可复用的预算核算表（数值为示例配置，非实测数据）。

表 4：Executor 容器内存预算示例（模拟配置，用于说明核算方法，非生产实测）

5.1 核数与内存的配比

每个 Executor 的核数（spark.executor.cores）决定了并发任务数，也决定了同一时刻有多少任务在争抢内存池。核数过多会让 Execution 池被多个任务同时挤压，spill 概率上升；核数过少则资源利用率低。经验上 4–5 核配 16–24 GB 堆是常见起点，但必须结合任务的对象大小分布验证。笔者认为，“每核内存”比“每 Executor 内存”更有指导意义：它直接对应单个任务可用的预算。

5.2 动态分配下的预算漂移

开启 spark.dynamicAllocation.enabled 后，Executor 数量随负载伸缩，但单个 Executor 的内存预算不变。风险在于缩容时正在 spill 的任务被中断，或扩容时新 Executor 尚未预热就接到大分区。建议配合 spark.dynamicAllocation.executorIdleTimeout 与 shuffle 服务的保留策略一起调，避免“缩容—重算”的抖动。

六、代码级瘦身：从 UDF 到 Join 的对象治理

参数调优的天花板是代码。同样一份逻辑，写法不同，内存占用可能差数倍。以下四类是最常见的“内存放大器”。

6.1 避免 UDF 返回大对象

Scala/Java UDF 的输入输出都要经过序列化与反序列化，中间对象落在 User Memory。若 UDF 内部构造 List、Map 或大字符串，这些对象在 UDF 返回前不会被回收。优先使用 Spark 内置函数（Catalyst 可优化、可代码生成），必须用 UDF 时尽量返回原始类型，避免嵌套结构。Pandas UDF（Arrow 向量化）能显著降低单行开销，但要注意 Arrow 内存也计入堆外/本地内存。

6.2 Join 的膨胀与倾斜

Broadcast Join 把小的那一侧广播到每个 Executor，若阈值设置不当（spark.sql.autoBroadcastJoinThreshold 默认 10 MB），会把大表误广播，直接撑爆 Storage 池。Sort-Merge Join 的倾斜分区则会让单个任务处理远超平均的数据量，表现为“大部分任务秒完，少数任务跑几小时然后 OOM”。AQE 的 skew join 处理能自动拆分倾斜分区，但需要开启 spark.sql.adaptive.enabled 与 spark.sql.adaptive.skewJoin.enabled。

6.3 缓存策略：不是所有中间结果都值得 cache

cache 把数据放进 Storage 池，看似省了重算，实则挤占了 Execution 池。对只被消费一次的 DataFrame，cache 是纯负担；对多次消费但体积巨大的，应改用 persist(StorageLevel.DISK_ONLY) 或检查点。判断标准很简单：缓存带来的重算节省是否大于它对 Execution 池的挤压成本。

6.4 分区粒度与文件大小

输入分区过大会让单任务内存需求陡增；分区过小则任务调度与元数据开销上升。结合 spark.sql.files.maxPartitionBytes（默认 128 MB）与 AQE 的 coalesce 分区合并，可以在读入阶段就把分区控制在合理区间。小文件问题不仅是 IO 问题，也是内存问题——每个分区都要在 Executor 上实例化任务上下文。

本文评述：代码级瘦身的收益往往被低估。笔者见过多个案例，仅把 UDF 换成内置函数、把误广播的大表改回 shuffle join，OOM 就消失了，参数一个没动。先改代码，再调参数，顺序不能反。

七、序列化与存储格式的取舍

序列化决定了对象在 shuffle、cache、广播时的字节形态。Kryo 相比 Java 原生序列化通常更紧凑、更快，Spark 官方文档建议在 shuffle 数据量大时启用 Kryo 并注册自定义类^[1][8]。但 Kryo 不是银弹：未注册的类会写入完整类名，反而变大；版本升级时的兼容性也需注意。对于列式分析场景，Parquet/ORC 的列裁剪与谓词下推能从源头减少读入数据量，比任何序列化优化都更根本。

表 5：序列化方式对比（综合 Spark 官方文档与社区实践，体积/速度为定性描述）^[1][8]

八、调优操作路径：七步排查法

把前面的分析收敛成一条可执行路径，是本文的落脚点。以下七步按“先定位、后核算、再改代码、最后调参”的顺序排列，避免一上来就改参数。

1. 定位故障域：确认是 Driver 还是 Executor，是堆内、堆外还是 GC overhead。看 exit code、日志首行异常、容器事件。
2. 对齐时间线：把 Spark UI 的 Stage/Task 指标与 GC 日志按时间对齐，找到 OOM 前 5 分钟的内存曲线拐点。
3. 看 spill 与 shuffle：Spill (memory) 持续增长说明 Execution 池过载；shuffle read 远大于 write 说明倾斜或分区不合理。
4. 核算预算：按表 4 逐项核对容器内存，确认 overhead 与堆外是否被漏算。
5. 改代码：UDF 换内置函数、误广播改 shuffle join、去掉无谓 cache、调整分区粒度。
6. 调内存参数：调整 memory.fraction、storageFraction、offHeap，一次只动一个变量并记录基线。
7. 调 GC：确认收集器、打开 GC 日志、按晋升速率与 Humongous 分配调整 region 与停顿目标。

每一步都应留下可对比的基线数据（运行时长、spill 字节数、Full GC 次数、峰值堆使用）。没有基线的调优无法判断是否真的改善。关于 AQE 的配置细节，可参考 Apache Spark 官方 SQL 性能调优文档^[9]；关于 GC 日志的解读，OpenJDK 的统一日志文档是权威入口^[7]；社区侧，Databricks 与 Cloudera 的工程博客提供了大量真实案例^[2][10]。视频与教程方面，Spark 官方文档的 Tuning 页面、以及各大云厂商的 Spark 调优实践课程都值得对照阅读。

九、前沿演进：AQE、向量化与 Spark 4.x

AQE（Adaptive Query Execution）自 Spark 3.0 引入、3.2 起默认开启，它把“运行时统计信息”引入优化决策，能动态合并小分区、拆分倾斜分区、切换 join 策略。这对 OOM 的意义在于：它把一部分原本需要人工预估的分区大小问题交给了运行时。但 AQE 不是万能药——它依赖 shuffle 阶段收集的准确统计，且倾斜拆分有阈值上限。笔者认为，AQE 降低了“分区估算错误”这一类 OOM 的概率，但没有改变“对象生命周期”与“GC 反馈”这两条主线，后者仍需代码与参数配合。

向量化执行（Vectorized Reader/Writer）与 Arrow 的引入，让批处理从“逐行”转向“逐批”，单次处理的数据量变大但对象数变少，GC 压力结构随之改变：年轻代分配速率下降，但单次分配体积上升，Humongous 风险增加。这提示调优重点要从“减少对象数”转向“控制批大小”。Spark 4.x 在连接器、向量化与 ANSI 模式上继续演进，社区也在讨论更细粒度的内存核算与可观测性^[11][12]。本文评述：工具在进步，但“预算—生命周期—反馈”这条分析主线不会过时，它只是换了观测手段。

十、结语与主要参考文献

Spark 的 OOM 调优之所以让人觉得“玄”，是因为它同时涉及内存预算、对象生命周期与 GC 反馈三个层面，而多数排查只停留在其中一个。把三者串成一条主线，先定位故障域、再核算预算、然后改代码、最后调参数与 GC，调优就从试错变成了可复现的工程流程。希望本文的七步排查法与预算核算表，能成为你下一次 OOM 复盘时的起点。