Flink 内存模型解释：从堆内到堆外的完整内存分配体系

Flink 作业跑着跑着突然 OOM是很多大数据工程师的噩梦。Heap OOM、Metaspace OOM、Direct buffer memory OOM、GC Overhead OOM各种 OOM 类型让人眼花缭乱。Flink 的内存模型到底是怎么设计的TaskManager 的总内存是如何分配到各个区域的堆内和堆外有什么区别Managed Memory 和 Network Memory 是干什么的RocksDB 状态存在哪里这篇从源码级别深入剖析 Flink 内存模型的完整分配体系。一、Flink 内存模型整体架构下面这张图是 Flink 内存模型整体架构采用嵌套包含关系展示 TaskManager 总内存的完整分配体系。Flink TaskManager 的内存模型是一个分层嵌套结构从外到内分为三层最外层TaskManager 总内存process.size。这是 TaskManager 进程的总内存包括 JVM 进程内存和 JVM 开销。通过taskmanager.memory.process.size配置默认 1728MB。这是容器化部署YARN/K8s时最重要的配置决定了容器申请的总内存。中间层JVM 进程内存flink.size。从总内存中减去 JVM Metaspace 和 JVM Overhead得到 Flink 可用的内存。通过taskmanager.memory.flink.size配置。JVM 进程内存分为堆内内存和堆外内存两大部分。最内层各内存区域。堆内内存Heap由 JVM GC 管理包括 Framework Heap框架堆默认 128MB和 Task Heap任务堆剩余堆内存。堆外内存Off-Heap / Direct由 Flink 直接管理不受 GC 影响包括 Managed Memory管理内存默认 40% 堆外和 Network Memory网络内存默认 10% 总内存。JVM 开销包括 JVM Metaspace元空间默认 128MB、JVM OverheadJVM 开销默认 10% 总内存、Direct Memory直接内存。理解这个嵌套结构是排查内存问题的基础。Heap OOM 说明 Task Heap 不足Direct buffer memory OOM 说明堆外内存不足Metaspace OOM 说明类元数据空间不足。二、内存区域详解下面这张图是内存区域详解包括6大内存区域的用途、默认配置和内存计算逻辑。2.1 Task Heap任务堆内存Task Heap 是用户任务使用的 JVM 堆内内存是 Flink 作业最核心的内存区域。类型JVM 堆内由 GC 管理默认大小剩余堆内存Flink Memory - Framework Heap - Network - Managed配置参数taskmanager.memory.task.heap.size用途用户算子执行、对象创建、HashMapStateBackend 状态存储、用户代码中的对象和集合Task Heap 是流处理小状态作业的主要内存区域。使用 HashMapStateBackend 时所有状态都存储在 Task Heap 中状态大小受堆内存限制。Task Heap 由 JVM GC 管理频繁创建对象会导致 GC 压力增大Full GC 会导致作业停顿。典型问题Heap OOMjava.lang.OutOfMemoryError: Java heap space。原因通常是状态过大、用户缓存无界、数据倾斜导致单 key 状态过大。解决方法增大 Task Heap、使用 RocksDBStateBackend、配置状态 TTL、优化用户代码缓存。2.2 Framework Heap框架堆内存Framework Heap 是 Flink 框架本身使用的堆内存。类型JVM 堆内由 GC 管理默认大小128MB配置参数taskmanager.memory.framework.heap.size用途Flink 框架代码、Akka 消息系统、调度器、Slot 管理、JobManager/TaskManager 框架对象Framework Heap 一般不需要调整默认 128MB 足够大多数场景。大集群数千 TM或复杂调度场景可适当增加到 256MB。Framework Heap 不足会导致框架层面的 OOM但这种情况比较少见。2.3 Managed Memory管理内存Managed Memory 是 Flink 管理的堆外内存是大状态作业的关键区域。类型JVM 堆外Direct Memory由 Flink 直接管理默认比例40% 堆外内存Flink Memory - Network配置参数taskmanager.memory.managed.fraction或taskmanager.memory.managed.size用途RocksDB 状态后端、批处理排序Sort、哈希表Hash Table、内存中缓存Managed Memory 是 Flink 1.10 之后引入的统一堆外内存管理机制。使用 RocksDBStateBackend 时所有状态都存储在 Managed Memory 中不受 JVM GC 影响性能稳定支持大状态TB 级。批处理作业的排序和哈希表也使用 Managed Memory。关键配置state.backend.rocksdb.memory.managedtrue默认开启RocksDB 的内存由 Flink 的 Managed Memory 统一管理避免 RocksDB 内存超限导致 OOM。RocksDB 内部分为 Block Cache数据块缓存默认 50% Managed、Write Buffer写缓冲默认 64MB × 2、Index Filter索引和布隆过滤器默认 10% Managed、其他开销迭代器、快照、Compaction。2.4 Network Memory网络内存Network Memory 是 Flink 网络传输使用的堆外内存。类型JVM 堆外Direct Memory由 Flink 直接管理默认比例10% 总内存Flink Memory范围 [min, max]配置参数taskmanager.memory.network.fraction、taskmanager.memory.network.min、taskmanager.memory.network.max用途数据传输缓冲ResultPartition/InputGate、Shuffle、网络通信、反压控制Network Memory 是数据在 TaskManager 之间传输的缓冲。上游算子通过 RecordWriter 将数据写入 ResultPartitionResultPartition 缓冲数据后通过 Netty 网络发送到下游下游 InputGate 接收数据后交给 RecordReader 反序列化。Network Memory 不足会导致反压和性能下降严重时会导致数据传输超时。关键配置taskmanager.network.memory.buffers-per-channel每个通道独占缓冲数Exclusive Buffers默认 2保证最低传输能力taskmanager.network.memory.floating-buffers-per-gate每个 InputGate 浮动缓冲数Floating Buffers默认 8在通道间动态分配taskmanager.network.memory.buffer-size网络缓冲大小默认 32KB高并行度、大流量作业需要调大 Network Memory建议设置network.fraction0.15-0.2。2.5 JVM Metaspace元空间JVM Metaspace 是 JVM 的类元数据空间。类型JVM 堆外本地内存由 JVM 直接管理默认大小128MB配置参数taskmanager.memory.jvm-metaspace.size用途JVM 类元数据、方法区、常量池、静态变量、JIT 编译后的代码Metaspace 是 JDK 8 之后替代 PermGen永久代的区域使用本地内存不受堆大小限制。Flink 作业中类加载较多动态代码生成、大量 UDF、Cep 模式编译时需要调大 Metaspace。典型问题java.lang.OutOfMemoryError: Metaspace。原因通常是类加载泄漏动态类加载未卸载、UDF 过多、代码生成量大。解决方法增大 Metaspace、检查类加载泄漏、减少动态类生成。2.6 JVM OverheadJVM 开销JVM Overhead 是 JVM 的其他开销内存。类型JVM 堆外本地内存由 JVM 直接管理默认比例10% 总内存范围 [min, max]配置参数taskmanager.memory.jvm-overhead.fraction、taskmanager.memory.jvm-overhead.min、taskmanager.memory.jvm-overhead.max用途线程栈Thread Stack、JNI 调用、代码缓存Code Cache、直接内存Direct Memory、GC 开销、其他本地内存JVM Overhead 是一个兜底区域覆盖 JVM 的各种额外内存需求。线程数多每个线程栈默认 1MB、JNI 调用频繁、直接内存使用多时需要调大。典型问题java.lang.OutOfMemoryError: Direct buffer memory。原因通常是直接内存使用超限Netty、RocksDB 未纳入 managed、JNI 调用内存泄漏。解决方法增大 JVM Overhead、开启 RocksDB managed 内存、检查 JNI 调用。三、内存计算逻辑Flink 的内存计算遵循固定的优先级和公式理解计算逻辑有助于合理配置内存。以taskmanager.memory.process.size4096MB为例第1步计算 JVM 开销 JVM Overhead 4096 × 0.1 409.6MB范围 [192MB, 1024MB] JVM Metaspace 128MB固定大小 第2步计算 Flink 可用内存 Flink Memory 4096 - 409.6 - 128 3558.4MB 第3步计算 Network Memory Network Memory 3558.4 × 0.1 355.84MB范围 [64MB, 1024MB] 第4步计算 Managed Memory Managed Memory (3558.4 - 355.84) × 0.4 1281.024MB 第5步计算 Task Heap Framework Heap 128MB固定大小 Task Heap 3558.4 - 128 - 355.84 - 1281.024 1793.536MB最终各区域大小Task Heap约 1794MB50.5% Flink MemoryManaged Memory约 1281MB36% Flink MemoryNetwork Memory约 356MB10% Flink MemoryFramework Heap128MB3.6% Flink MemoryJVM Metaspace128MB3.1% 总内存JVM Overhead约 410MB10% 总内存可以看到默认配置下 Task Heap 占比最大约 50%适合流处理小状态作业。大状态作业需要调大 Managed Memory 比例批处理作业需要同时调大 Managed 和 Network。四、不同场景内存配置对比不同场景下各内存区域的需求差异很大合理配置是性能优化的关键。场景Task HeapManagedNetwork说明流处理小状态大小中HashMapStateBackend状态在堆内算子执行需要大量堆内存流处理大状态中大中RocksDBStateBackend状态在堆外Managed 是关键堆内存只用于算子执行批处理中大大排序/哈希表使用 ManagedShuffle 使用 Network堆内存需求中等高并发网络中中大高并行度、大流量网络缓冲需求大反压风险高复杂 CEP/规则大中中CEP 模式匹配、复杂规则引擎堆内存需求大状态中等配置建议流处理小状态managed.fraction0.2network.fraction0.1剩余给 Task Heap流处理大状态managed.fraction0.5network.fraction0.15Task Heap 保持中等批处理managed.fraction0.5network.fraction0.2Task Heap 保持中等高并发网络managed.fraction0.3network.fraction0.25增加网络缓冲五、内存调优与最佳实践下面这张图是内存调优与最佳实践包括 OOM 排查流程、内存泄漏原因、GC 调优、RocksDB 内存配置。5.1 OOM 排查流程遇到 OOM 时按照以下5步排查确认 OOM 类型查看日志中的 OOM 错误信息确认是 Heap、Metaspace、Direct buffer memory 还是 GC Overhead。不同类型对应不同的内存区域。查看日志堆栈分析 OOM 时的堆栈信息定位是哪个算子、哪段代码导致的内存问题。堆栈信息是排查的关键线索。分析内存快照使用jmap -dump生成堆转储文件用 MATMemory Analyzer Tool或 JProfiler 分析大对象和内存泄漏点。调整内存配置根据分析结果增大对应内存区域Task Heap / Managed / Network / Metaspace / Overhead优化状态后端和用户代码。监控验证调整后重新运行作业通过 Flink Web UI 监控各内存区域的使用情况验证修复效果确保不再 OOM。5.2 内存泄漏常见原因内存泄漏是 Flink 作业最常见的内存问题常见原因有6个状态未清理Keyed State 未配置 TTL状态无限增长。这是最常见的原因必须为所有有状态算子配置 TTL。连接未关闭open() 中创建的外部连接数据库、Redis、HTTP在 close() 中未关闭连接泄漏导致内存和资源耗尽。缓存无界用户代码中使用 HashMap/List 做缓存但没有上限数据持续增长直到 OOM。必须使用 LRU 缓存或设置最大容量。广播变量过大Broadcast State 数据量过大每个 TaskManager 全量存储内存占用 广播数据大小 × TM 数量。线程泄漏用户代码中创建线程Thread/ExecutorService未关闭线程数持续增长每个线程栈占用约 1MB 内存。类加载泄漏动态类加载如 Groovy/Janino 脚本编译后类未卸载Metaspace 持续增长最终 Metaspace OOM。5.3 GC 调优Task Heap 由 JVM GC 管理GC 调优对流处理作业的稳定性至关重要。关键 GC 参数GC 收集器推荐 G1JDK 8 默认或 ZGCJDK 11低延迟。大堆8GB推荐 G1低延迟场景推荐 ZGC。MaxGCPauseMillis最大 GC 停顿时间流处理建议设置 100-200ms。设置过小会导致 GC 频率增加设置过大会导致单次停顿时长。InitiatingHeapOccupancyPercent触发并发 GC 的堆占用比例默认 45%。流处理作业建议设置 35-40%提前触发 GC 避免 Full GC。MaxDirectMemorySize最大直接内存必须与 Flink 堆外配置Managed Network一致否则可能导致直接内存 OOM。GC 调优建议堆内存不要过大建议 ≤ 8GB过大导致 GC 停顿长大状态用 RocksDB 堆外存储开启 GC 日志-Xlog:gc*:filegc.log:time,level,tags便于分析 GC 行为关注 Full GC 频率Full GC 会导致作业长时间停顿应通过调优避免使用 G1 时设置-XX:UseG1GC -XX:MaxGCPauseMillis2005.4 RocksDB 内存配置使用 RocksDBStateBackend 时RocksDB 的内存管理是关键。RocksDB 内存分为4层Block Cache数据块缓存读性能关键默认占 Managed Memory 的 50%。缓存热点数据块减少磁盘 IO。Write Buffer写缓冲MemTable写性能关键默认 64MB × 2每个 Column Family 两个 MemTable。数据先写入 MemTable满后 flush 到磁盘。Index Filter索引和布隆过滤器查询加速默认占 Managed Memory 的 10%。加速数据查找减少磁盘 IO。其他开销迭代器、快照、Compaction 开销使用剩余 Managed Memory。关键配置state.backend.rocksdb.memory.managedtrue开启 Managed 内存管理RocksDB 内存由 Flink 统一控制避免 OOMstate.backend.rocksdb.memory.write-buffer-ratio0.5Write Buffer 占 Managed 的比例state.backend.rocksdb.memory.high-prio-pool-ratio0.1Index Filter 高优先级池比例state.backend.rocksdb.block.blocksize32KB数据块大小默认 4KB大状态建议 32KB六、关键配置参数# TaskManager 总内存容器化部署最重要的配置taskmanager.memory.process.size:4096MB# Flink 可用内存不包含 JVM 开销taskmanager.memory.flink.size:3558MB# 任务堆内存用户算子和 HashMapStateBackend 状态taskmanager.memory.task.heap.size:1794MB# 框架堆内存Flink 框架使用taskmanager.memory.framework.heap.size:128MB# 管理内存比例RocksDB 状态、批处理排序、哈希表taskmanager.memory.managed.fraction:0.4# 网络内存比例数据传输缓冲、Shuffletaskmanager.memory.network.fraction:0.1taskmanager.memory.network.min:64MBtaskmanager.memory.network.max:1024MB# JVM 元空间大小taskmanager.memory.jvm-metaspace.size:128MB# JVM 开销比例taskmanager.memory.jvm-overhead.fraction:0.1taskmanager.memory.jvm-overhead.min:192MBtaskmanager.memory.jvm-overhead.max:1024MB# 网络缓冲配置taskmanager.network.memory.buffers-per-channel:2taskmanager.network.memory.floating-buffers-per-gate:8taskmanager.network.memory.buffer-size:32KB# RocksDB 内存管理state.backend:rocksdbstate.backend.rocksdb.memory.managed:truestate.backend.rocksdb.memory.write-buffer-ratio:0.5state.backend.rocksdb.memory.high-prio-pool-ratio:0.1# 每个 TaskManager 的 Slot 数taskmanager.numberOfTaskSlots:1# 默认并行度parallelism.default:1七、常见问题与最佳实践常见问题Heap OOMJava heap space原因状态过大HashMapStateBackend、用户缓存无界、数据倾斜、对象创建频繁。解决增大 Task Heap、改用 RocksDBStateBackend、配置状态 TTL、优化用户代码缓存、解决数据倾斜。Direct buffer memory OOM原因堆外内存不足Managed Network 配置过小、RocksDB 未开启 managed 内存、Netty 直接内存超限。解决增大 Managed/Network Memory、开启 RocksDB managed 内存、增大 JVM Overhead、检查 MaxDirectMemorySize 配置。Metaspace OOM原因类加载泄漏、UDF 过多、动态代码生成量大、CEP 模式编译。解决增大 JVM Metaspace、检查类加载泄漏、减少动态类生成、复用 UDF 实例。GC Overhead OOM原因堆内存不足、对象创建频繁、Full GC 频繁、GC 时间过长。解决增大 Task Heap、优化对象创建复用对象、避免频繁序列化、调优 GC 参数、改用 RocksDB 减少堆内存压力。Container killed by YARN/K8s原因容器实际内存使用超过申请的总内存process.size通常是 JVM Overhead 不足或堆外内存泄漏。解决增大 process.size、增大 JVM Overhead、检查堆外内存泄漏、开启 RocksDB managed 内存。内存使用持续增长原因状态未清理无 TTL、用户缓存无界、连接泄漏、线程泄漏、类加载泄漏。解决配置状态 TTL、用户缓存设置上限、close() 中关闭连接和线程、检查类加载泄漏。最佳实践大状态用 RocksDB状态 1GB 必须使用 RocksDBStateBackend状态存储在堆外 Managed Memory不受 JVM GC 影响避免 Full GC 导致的作业停顿支持 TB 级大状态。配置状态 TTL为所有有状态算子的 Keyed State 配置 TTLTime-To-Live自动清理过期状态防止状态无限增长导致 OOM。TTL 支持 processing time 和 event time可在 StateDescriptor 中配置。合理设置堆大小Task Heap 不要过大建议 ≤ 8GB过大导致 GC 停顿长影响流处理延迟。大状态用 RocksDB 堆外存储堆内存只用于算子执行和临时对象。开启 Managed 内存RocksDB 必须开启state.backend.rocksdb.memory.managedtrue由 Flink 的 Managed Memory 统一管理 RocksDB 内存避免 RocksDB 内存超限导致容器 OOM。监控内存使用通过 Flink Web UI 监控各内存区域的使用情况Heap / Managed / Network / Direct及时发现内存泄漏和 OOM 风险。关注 MetricsStatus.Flink.Memory.Managed.Used、Status.Flink.Memory.Network.Used。资源关闭在 close()所有外部资源数据库连接、Redis 连接、HTTP 客户端、文件句柄、线程池必须在 RichFunction 的 close() 方法中关闭防止资源泄漏导致内存和连接耗尽。使用 try-with-resources 确保关闭。避免用户缓存无界用户代码中的缓存HashMap/List/Guava Cache必须设置最大容量和过期策略使用 LRU 缓存或 Caffeine防止数据持续增长导致 OOM。不要在静态变量中缓存大量数据。八、总结Flink 内存模型是一个分层嵌套结构TaskManager 总内存process.size JVM 进程内存flink.size JVM Metaspace JVM Overhead。JVM 进程内存分为堆内内存Framework Heap Task Heap和堆外内存Managed Memory Network Memory。Task Heap用于用户算子执行和 HashMapStateBackend 状态由 JVM GC 管理Managed Memory用于 RocksDB 状态、批处理排序和哈希表由 Flink 直接管理Network Memory用于数据传输缓冲和 ShuffleJVM Metaspace用于类元数据JVM Overhead用于线程栈、JNI、代码缓存等其他开销。内存计算遵循固定公式Flink Memory Process Size - Metaspace - OverheadNetwork Flink Memory × network.fractionManaged (Flink Memory - Network) × managed.fractionTask Heap Flink Memory - Framework Heap - Network - Managed。理解计算逻辑有助于合理配置各内存区域。内存调优的核心是合理分配各内存区域和防止内存泄漏。OOM 排查5步确认 OOM 类型 → 查看日志堆栈 → 分析内存快照 → 调整内存配置 → 监控验证。内存泄漏常见原因包括状态未清理、连接未关闭、缓存无界、广播变量过大、线程泄漏、类加载泄漏。GC 调优推荐 G1 收集器设置 MaxGCPauseMillis200ms大堆可考虑 ZGC。RocksDB 内存分为 Block Cache、Write Buffer、Index Filter、其他开销四层开启 managed 内存由 Flink 统一管理。大状态用 RocksDB、配置状态 TTL、合理设置堆大小、开启 Managed 内存、监控内存使用、资源关闭在 close()、避免用户缓存无界这7条最佳实践可以显著提高 Flink 作业的内存稳定性减少 OOM 和内存泄漏问题为生产环境的稳定运行提供保障。