谢丽鹿做了几年 Flink 作业的平台运维，我印象最深的不是哪次大促压测，而是 1.10 到 1.11 那两次升级带来的内存配置体系变动。很多同事升级完第一件事就是发现作业内存不够用，JVM 堆神秘地“缩水”了一块，甚至直接 OOM。问题根源很简单：Flink 的内存配置从“heap 时代”切换到“process/flink 时代”，旧参数不生效了，新参数又没设对。
这篇文章专门讲清楚这条迁移线。我会先对比两代内存模型，再分别拆 1.10 和 1.11 的关键变化，然后用一个 6GB TaskManager 的实例手把手算一遍内存分配，最后给出我踩过的坑和排查思路。适合正在升级 Flink、或者准备给作业做内存精细调优的读者——不管你是平台开发还是用 Flink 的业务同学，看完基本能独立完成参数翻译和问题定位。
1. 新老内存模型：从一把梭到分层管理
1.1 老模型为什么难用
在 1.9 及更早版本，TaskManager 的内存基本靠一个参数拍板：taskmanager.heap.size。你给它设 6GB，它就像是把一个袋子里的所有东西都塞进 JVM 堆，包括用户代码的堆内存、框架自身的堆内存、托管给 Flink 管理的状态内存，甚至网络缓冲也要从堆里切一块出来。配合老的 taskmanager.memory.fraction（默认 0.7）和 taskmanager.network.memory.fraction（默认 0.1），Flink 在启动时按比例从堆里划出托管内存和网络内存。
这个设计在作业规模小的时候问题不大，但一旦上了容器、YARN，痛点就暴露了：堆内存不等于进程内存，JVM 还有 metaspace、线程栈、JIT 编译产物这些堆外开销；RocksDB 状态后端又需要大量 native 内存，老模型里这些全在 heap.size 外面“裸奔”，容器容易被撑爆。最要命的是，你没办法精确回答一个问题：容器申请了 6GB，Flink 到底能用到多少堆、多少堆外、多少交给操作系统？
1.2 新模型的总览：Process Memory 和 Flink Memory 两层结构
1.10 引入的新模型（FLIP-49 设计）把内存分成了两个层级，这个设计一直延续到今天。核心公式是：
code复制Total Process Memory = Total Flink Memory + JVM Metaspace + JVM Overhead
其中：
code复制Total Flink Memory = JVM Heap（Framework Heap + Task Heap） + Managed Memory + Network Memory + Off-heap（Framework + Task）
说白了，process.size 站在容器视角，管的是整个进程能用的总内存；flink.size 站在 Flink 运行时视角，管的是算子和框架真正能支配的内存。中间差出来的 JVM Overhead 和 JVM Metaspace，就是给 JVM 自己留的口粮。
为了方便对照，我把两代模型的关键差异整理成表：
| 维度 | Heap 时代（1.9 之前） | Process/Flink 时代（1.10+） |
|---|---|---|
| 主入口参数 | taskmanager.heap.size |
taskmanager.memory.process.size 或 taskmanager.memory.flink.size |
| 托管内存 | 从堆里按 taskmanager.memory.fraction 切 |
taskmanager.memory.managed.fraction（默认 0.4）独立计算 |
| 网络内存 | 从堆里按 taskmanager.network.memory.fraction 切 |
独立组件 taskmanager.memory.network.*，默认占 Flink Memory 的 10% |
| JVM 开销 | 无独立配置，基本靠容器 cutoff 兜底 | taskmanager.memory.jvm-overhead.* 独立预留 |
| 容器内存 | 堆 + cutoff 估算 | process.size 直接对应容器内存 |
提示：升级之后如果看到某个老参数被日志标记为 deprecated，不要慌，那是 Flink 在提醒你该换新参数了。新旧混用不是不行，但很容易踩“以为生效其实没生效”的坑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 1.10 新模型细节拆解：FLIP-49 的设计逻辑
2.1 为什么一定要拆成 process 和 flink 两个入口
不少人刚接触新模型时都会问：既然有 process.size 了，为什么还要 flink.size？这不是冗余，而是为了适配不同的部署方式。
如果你的 TaskManager 跑在 YARN 容器、Kubernetes Pod 或者 Docker 容器里，容器给多少内存你就填多少到 taskmanager.memory.process.size，Flink 会自动从里面扣除 JVM 开销、metaspace，剩下的才是 Flink 能用的内存。这种方式最省心，也是官方推荐的首选。
但有些团队会用脚本或外部工具统一设置 -Xmx、-XX:MaxMetaspaceSize 这些 JVM 参数，此时 JVM 的堆外开销已经被外部控制了，Flink 再去算 JVM Overhead 就会重复。这种情况下你只需要告诉 Flink 它自己能支配多少：设置 taskmanager.memory.flink.size，同时把 JVM 相关参数交给外部管理。简单记忆：容器内存归 process，Flink 自治归 flink。
2.2 新模型里的六块内存，分别管什么
我用一次 Word 写文档的经历来类比：process.size 是整张桌子，JVM Heap 是电脑的内存条，Managed Memory 是给“草稿箱”预留的空间，Network Memory 是快递通道，JVM Overhead 是电脑散热和电源的余量。每个部件功能不同，调优思路自然也不一样。
JVM Heap：细分为 Framework Heap 和 Task Heap。Framework Heap 默认 128MB，给 Flink 框架内部用；Task Heap 是用户算子、窗口、状态访问的常规堆空间，也是平时最容易 OOM 的地方。
Managed Memory：这是 Flink 托管的内存，主要用于 RocksDB 状态后端（native 内存）和批量算子（排序、哈希聚合）的内部缓冲。配置上二选一：taskmanager.memory.managed.fraction（默认 0.4）按比例算，或者 taskmanager.memory.managed.size 指定固定值。用 RocksDB 时这块内存会直接分配给 RocksDB 的 block cache 和 write buffer，是状态后端的“粮仓”。
Network Memory：数据在算子之间传输时申请网络缓冲用的。默认取 total Flink Memory 的 10%，但被 taskmanager.memory.network.min（64MB）和 taskmanager.memory.network.max（1GB）夹在中间。数据 shuffle 量大的作业，很容易在这里报“Insufficient number of network buffers”。
Off-heap（Framework + Task）：框架和用户代码里显式申请的堆外内存。框架默认各 128MB，Task 默认 0。如果你的 UDF 里用了 DirectByteBuffer 或者接了一些 JNI 库，就得给 Task Off-heap 留空间。
JVM Overhead：JVM 运行时的线程栈、代码缓存、GC 结构等额外开销。默认按 total process memory 的 10% 计算，区间是 192MB 到 1GB。这个参数经常被忽略，但它恰恰是“容器被撑爆”的头号嫌疑犯。
2.3 两个入口的选型建议
我的经验是：绝大多数场景直接用 taskmanager.memory.process.size，让 Flink 自己算内部结构。只有当你有强理由自己管 JVM 参数（比如公司有统一的 JVM 基线规范）时才用 taskmanager.memory.flink.size。用 flink.size 意味着你同时要显式设置 taskmanager.memory.jvm-overhead.* 和 taskmanager.memory.jvm-metaspace.size，不然 JVM 的真实内存和 Flink 的预期会脱节。
3. 1.11 的关键变化：JobManager 内存模型与参数废弃
3.1 TaskManager 侧：旧名字彻底落幕
1.10 其实还留了一些过渡参数，比如 taskmanager.heap.size、taskmanager.memory.heap，以及老的容器 cutoff 逻辑。到 1.11，Flink 正式宣布这些参数废弃，并计划在未来版本移除。升级到 1.11 后，如果日志出现这样的告警：
code复制The configuration option 'taskmanager.heap.size' is deprecated and will be ignored in the future versions.
别犹豫，这表示你的配置文件里还留着老时代的遗物。正确做法是删掉所有老的 heap 入口参数，统一改用 taskmanager.memory.process.size 或 taskmanager.memory.flink.size。
同时，1.11 还把网络内存的默认行为固定下来：min 64MB、max 1GB、fraction 0.1。这意味着即使你完全不配置网络内存，Flink 也会按这个规则从总内存里切一块独立的网络缓冲池，不再像老版本那样直接从堆里“抢”。
3.2 JobManager 内存模型上线（FLIP-43）
1.11 最大的变化其实在 JobManager。之前 JM 的内存只有一个简单的 jobmanager.heap.size，调度一多就各种怪问题。FLIP-43 之后，JobManager 也拥有了和 TaskManager 同款的规范：
jobmanager.memory.process.size：默认 1600MB，JM 进程总内存jobmanager.memory.flink.size：JM 的 Flink 内存，不设时由 process 推导jobmanager.memory.heap.size：默认 128MB，JM 的 JVM 堆jobmanager.memory.jvm-metaspace.size：默认 256MBjobmanager.memory.jvm-overhead.fraction / min / max：默认 0.1 / 192MB / 1GB
注意 JM 的堆默认只有 128MB，这个值在实际生产中偏小。如果你的集群上同时跑的作业很多、并发调度量大，我建议直接把 jobmanager.memory.heap.size 提到 512MB 以上，不然 JobManager 会频繁 Full GC，表现为“作业提交很慢”或者“Web UI 卡顿”。这是我在 1.11 上线后踩过最典型的坑。
3.3 升级检查清单
升级到 1.11 之前，我建议按下面的清单扫一遍配置：
- 全局搜
heap.size、memory.heap，确认没有这些老参数残留 - 确认
containerized.heap-cutoff-ratio、yarn.heap-cutoff-ratio这类 cutoff 参数已经移除或不再生效 - 确认
taskmanager.memory.process.size与容器/YARN 申请的内存一致 - 检查
jobmanager.memory.process.size，生产环境建议至少 1.6GB 起跳 - 如果用了 RocksDB，确认
state.backend.rocksdb.memory.managed为 true（默认就是），让 RocksDB 的 block cache 纳入 managed memory 管理，避免内存失控
4. 完整迁移实操：6GB TaskManager 手把手换算
4.1 老配置翻译成新配置
假设你线上有一份老配置：
code复制taskmanager.heap.size: 6144m
taskmanager.memory.fraction: 0.7
taskmanager.network.memory.fraction: 0.1
升级到 1.11 后，第一步不是去换算堆，而是把整个容器视角搬过来。如果这台 TaskManager 跑在 YARN 容器里，容器内存就是 6GB，那么直接写：
code复制taskmanager.memory.process.size: 6144m
其他参数先全部不设，让 Flink 按默认值把内存切成下面这些组件。然后再根据状态后端类型微调：用了 RocksDB，taskmanager.memory.managed.fraction 可以保持 0.4 甚至调到 0.5；如果只是普通 heap 状态后端、状态量也不大，建议降到 0.2~0.3，把更多内存还给 Task Heap。
4.2 手算一遍：6144MB 是怎么分配的
我们按 process.size = 6144MB、全部默认参数来算，这样你能直观看到新模型里每块内存的流向：
- JVM Overhead：取
max(0.1 × 6144, 192MB)= 614MB，没超过 1GB 上限，所以是 614MB - JVM Metaspace：默认 256MB
- Total Flink Memory：6144 - 614 - 256 = 5274MB
- Framework Off-heap：默认 128MB；Task Off-heap：默认 0
- Network Memory：
0.1 × 5274 = 527MB，在 [64MB, 1GB] 区间内，取 527MB - Framework Heap：默认 128MB
- Managed Memory：
0.4 × (5274 - 128 - 0 - 527 - 128) ≈ 1796MB（注意计算时先扣掉 off-heap 和 network，再乘比例） - Task Heap：5274 - 128 - 128 - 0 - 527 - 1796 ≈ 2695MB
也就是说，同是 6GB 的 TaskManager，新模型下 JVM 堆（Framework + Task）加起来大概 2.8GB，比老模型明显小。这是因为 managed、network、overhead 都被拆出来了。看到这个数字不要慌，它不是“内存被吞了”，而是以前被算在堆里的托管内存和网络内存现在单独记账了。
4.3 用 Web UI 和命令验证内存布局
配置完之后，怎么确认内存真的按预期分配？两个办法：
一是直接在 Web UI 的 TaskManager 页面看内存模型图，Flink 会把 JVM Heap、Managed、Network、JVM Overhead、Metaspace 各占多少画成一张非常直观的分段图。这个图是排查内存问题最快捷的入口。
二是看日志。TaskManager 启动日志里会打印类似下面的内存布局：
code复制Memory usage:
JVM Heap: 2695MB
Managed Memory: 1796MB
Network Memory: 527MB
JVM Overhead: 614MB
JVM Metaspace: 256MB
如果发现某一块和预期差得太多，再回头检查对应的 fraction 或 size 参数。
4.4 不同场景的参数模板
我整理了三套常见场景的模板，可以直接抄作业（以 6GB 容器为例）：
| 场景 | 关键参数 | 说明 |
|---|---|---|
| 轻状态、高吞吐（heap 状态后端） | process.size: 6144m、managed.fraction: 0.2 |
把托管内存降到 20%，堆更充裕 |
| 大状态、RocksDB | process.size: 8192m、managed.fraction: 0.5、jvm-overhead.fraction: 0.15 |
容器升到 8GB，给 RocksDB 更大空间 |
| 窗口聚合多、shuffle 重 | process.size: 6144m、network.fraction: 0.15 |
网络缓冲加大，减少反压和 buffer 不足 |
5. 常见问题与排查技巧实录
5.1 迁移后 JVM 堆变小，GC 频繁怎么办
这是升级后最常见的现象：配置里啥都没改，taskmanager.heap.size 也还在，但实际堆变小了。原因多半是旧配置的 taskmanager.heap.size 在 1.11 被忽略，Flink 走了 process.size 默认分支，而 managed 和 network 是独立切走的。
排查时先看 Web UI 的内存模型图，确认 managed 占比是不是虚高。如果状态并不大，把 taskmanager.memory.managed.fraction 调到 0.2 左右，GC 压力会立刻缓解。如果状态确实很大，那就得老实加容器内存，而不是牺牲 managed 去换堆，否则 RocksDB 性能会明显劣化。
5.2 网络内存不足导致作业失败
报错里出现 Insufficient number of network buffers 或者反压一直打满，优先怀疑 network memory。默认 10% 在极端 shuffle 场景下不够用。
调整方式有两种：直接给固定值 taskmanager.memory.network.min/max，或者改比例 taskmanager.memory.network.fraction: 0.15。我个人的习惯是保留 fraction，同时把 max 上限调高，避免小作业浪费内存、大作业又不够。改完记得重启 TaskManager 再观察 Web UI 的 network 使用率曲线。
5.3 本地内存越界导致的进程崩溃
这类问题最隐蔽，表现也最吓人：TaskManager 进程突然消失，日志里可能出现 JNI 相关的崩溃记录，Windows 下还可能看到类似 0xC0000005 (memory access violation) 的内存访问违例，或者 Linux 下容器被 OOM Killer 直接干掉。
这通常不是 JVM 堆的问题，而是 native 内存失控。常见诱因有三个：RocksDB 的 block cache 没有纳入 managed memory 管理；某些第三方库在堆外申请了大量内存；JVM Overhead 设置得太紧，线程一多就爆。排查时用容器视角：在 TaskManager 所在节点上观察进程的 RSS 内存，而不是只看 JVM 堆。如果 RSS 接近 process.size 还在涨，多半是堆外泄漏。对策是确认 state.backend.rocksdb.memory.managed=true，并适当放大 taskmanager.memory.jvm-overhead.fraction，给 JVM 自己留足余地。
5.4 新旧参数混用告警怎么清理
升级后日志里出现 deprecated 告警，很多人选择无视。但我的建议是趁着上线窗口一次性清干净。新旧参数混用最危险的情况是：你以为 taskmanager.memory.heap 还在控制堆，实际上新模型下的堆是由 process.size 推导出来的，两边不一致，线上出了问题很难定位。搜索配置里所有 heap、cutoff、memory.fraction 老名字，全部替换成新模型参数，再对照 Web UI 验证一遍，这一步值得做。
5.5 排查问题时的参数速查表
| 想确认的内容 | 查看位置 / 参数 |
|---|---|
| 总内存是否和容器一致 | taskmanager.memory.process.size |
| JVM 堆实际大小 | Web UI TaskManager 内存模型图 |
| 状态内存够不够 | taskmanager.memory.managed.fraction / managed.size |
| 网络缓冲是否不足 | taskmanager.memory.network.min/max/fraction |
| JVM 额外开销是否过小 | taskmanager.memory.jvm-overhead.min/fraction/max |
| JM 是否频繁 GC | jobmanager.memory.heap.size / jobmanager.memory.process.size |
| RocksDB 内存是否失控 | state.backend.rocksdb.memory.managed |
最后再分享一个经验：做这套迁移时，最难的不是背参数，而是改变“看内存只看堆”的惯性。process/flink 时代要求你站在容器视角看总账，再往下一层一层拆。我每次调优都是先定容器总内存，再根据状态后端类型决定 managed 和 task heap 的比例，最后用 Web UI 的内存模型图复核。这套流程跑通之后，Flink 作业的内存问题基本都能在十分钟内定位到具体组件。