1、先搞清两个“总量”概念：Total Flink Memory vs Total Process Memory
Flink JVM 进程的总进程内存（Total Process Memory），包含两部分：
- Total Flink Memory：Flink 应用实际可用的内存（JVM Heap + Off-heap/Direct/Native 等）
- JVM 自身开销：比如 Metaspace、JVM Overhead 等
你最常用的两组开关就是：
TaskManager：
taskmanager.memory.flink.size（Total Flink Memory）taskmanager.memory.process.size（Total Process Memory）
JobManager：
jobmanager.memory.flink.size（Total Flink Memory）jobmanager.memory.process.size（Total Process Memory）
其余组件会在默认值或你额外配置的基础上自动推导。 (nightlies.apache.org)
怎么选更合适？
- Standalone/物理机/VM：更常用
*.memory.flink.size，你声明“给 Flink 本体多少内存”。 (nightlies.apache.org) - Kubernetes / YARN 容器化：更常用
*.memory.process.size，它更贴近“容器申请/限制的大小”。 (nightlies.apache.org)
2、必须三选一：不配就启动失败（很多人第一次就卡在这里）
除本地执行外，Flink 要求你至少显式配置下面三种方式中的一种，否则会直接启动失败： (nightlies.apache.org)
方式 A：配置 Total Flink Memory
taskmanager.memory.flink.size/jobmanager.memory.flink.size
方式 B：配置 Total Process Memory
taskmanager.memory.process.size/jobmanager.memory.process.size
方式 C：配置关键内部组件（更细粒度，风险也更高）
- TaskManager：
taskmanager.memory.task.heap.size+taskmanager.memory.managed.size - JobManager：
jobmanager.memory.heap.size
- TaskManager：
注意：不推荐同时显式配置 Total Process Memory 和 Total Flink Memory，很容易产生冲突，导致部署失败。 (nightlies.apache.org)
3、你配的这些值，最终会怎么落到 JVM 参数上？
Flink 启动进程时，会根据你的配置（或推导结果）显式添加关键 JVM 参数：
-Xmx/-Xms- TaskManager：Framework + Task Heap
- JobManager：JVM Heap
-XX:MaxDirectMemorySize- TaskManager：Framework + Task Off-heap + Network Memory
- JobManager：只有在开启
jobmanager.memory.enable-jvm-direct-memory-limit时才会加 Direct memory 限制
-XX:MaxMetaspaceSize- 两者都是 JVM Metaspace
这解释了两个常见现象：
- TaskManager Direct buffer OOM通常和 MaxDirectMemorySize（以及网络内存/Off-heap）有关
- JobManager 是否限制 Direct memory取决于那个 enable 开关 (nightlies.apache.org)
4、“按比例 + min/max 夹逼”的两类组件：JVM Overhead & Network Memory
Flink 里有些组件既可以按比例从“总量”里切，也受 min/max 约束，超出范围就启动失败：
- JVM Overhead：可以是 Total Process Memory 的一个 fraction，同时受 min/max 限制
- Network Memory：TaskManager 才有，通常可作为 Total Flink Memory 的 fraction，也受 min/max 限制 (nightlies.apache.org)
理解这个规则很关键：
- 你不显式配组件大小时，Flink 会按 fraction 算，再用 min/max 夹逼到合法范围
- 你把 min=max，相当于把该组件“钉死”为固定值
- 如果你把总量和其他组件都配得太死，fraction 可能被忽略，Overhead/Network 变成“剩余值”，剩余值仍必须落在 min/max 内，否则同样启动失败 (nightlies.apache.org)
5、两套落地模板：Standalone 与 K8s/YARN 的“更稳”写法
下面给你两种“少踩坑”的思路（示例值可按你集群资源与作业特性替换）。
模板 A：Standalone（更推荐从 Total Flink Memory 入手）
# flink-conf.yamljobmanager.memory.flink.size:2048mtaskmanager.memory.flink.size:8192m# 其余（Managed/Network/JVM Overhead 等）先让 Flink 推导# 真遇到 Direct buffer OOM / 网络缓冲不足，再针对性调 Network/Off-heap适用：你更关心“Flink 本体能用多少”，而不是容器边界。 (nightlies.apache.org)
模板 B：Kubernetes / YARN（更推荐从 Total Process Memory 对齐容器）
# flink-conf.yamljobmanager.memory.process.size:3072mtaskmanager.memory.process.size:10240m# 建议：如果你对网络/overhead 很敏感，可再加 min/max 来防止推导过小或过大# 但不要一上来就把所有组件都钉死，容易冲突适用：你希望 Flink 进程内存与容器 request/limit 一致，避免 “Container Memory Exceeded”。 (nightlies.apache.org)
6、常见报错怎么对症下药（比“盲调 -Xmx”更有效）
Flink 官方把内存相关问题也按症状拆开了，你可以按下面思路快速定位： (nightlies.apache.org)
IllegalConfigurationException
通常是值非法（负数、fraction>1）或配置冲突（总量/组件互相打架）。优先检查异常里提到的组件对应的配置项。 (nightlies.apache.org)OutOfMemoryError: Java heap space
说明 Heap 太小：提高 total memory（或直接提高 TaskManager task heap / JobManager heap）。 (nightlies.apache.org)OutOfMemoryError: Direct buffer memory
Direct memory 限制太小，或有 direct memory 泄漏/未计入。重点检查 Off-heap/Network 的配置与 Flink 设置的 JVM 参数。 (nightlies.apache.org)- 容器超限（Container Memory Exceeded）
优先用*.memory.process.size对齐容器边界，并给 JVM Overhead 留足空间。 (nightlies.apache.org)
