一、寫在前面：為什么 Flink 的內存如此與眾不同  

<i id='o0jdn'></i>

在離線批處理時代，“MapReduce + 大磁盤”就能解決大部分問題；而在毫秒級延遲的流式計算場景里，數據像無盡的河流涌來，磁盤很快成為瓶頸。Flink 通過精巧的內存模型，把“計算”與“存儲”融合在內存中，既保證了低延遲，又兼顧了高吞吐。理解這套模型，是調好 Flink 作業的第一步，也是避免 OOM、GC 風暴、背壓雪崩的關鍵。本文用近四千字，帶你走完 Flink 內存管理的完整鏈路。

二、宏觀鳥瞰：Flink 進程的兩大角色  

1. JobManager（JM）  
   作業的“大腦”，負責資源調度、元數據管理、故障恢復。  
2. TaskManager（TM）  
   作業的“肌肉”，真正執行 Source、Map、Sink 等算子。  
兩者均運行在 JVM 之上，但內存劃分策略截然不同：JM 以“穩定”為主，TM 以“彈性”為先。

三、TaskManager 內存四分法  

官方文檔把 TM 內存切成四大塊：  
- Heap：Java 對象、用戶函數、狀態快照。  
- Off-Heap：網絡緩沖、RocksDB 狀態、DirectBuffer。  
- Net：網絡棧專用內存，避免與計算爭用。  
- Framework：Flink 自身框架代碼、線程棧。  
每一塊都有獨立上限，超標即觸發背壓或 OOM。

四、Heap 區域：對象與 GC 的戰場  

1. 新生代（Eden + Survivor）  
   存放短生命周期的中間結果，Minor GC 頻繁但停頓短。  
2. 老年代（Old）  
   存放長生命周期的 keyed-state、窗口緩沖，Major GC 停頓長。  
3. 元空間（Metaspace）  
   類加載器、UDF 動態類膨脹，需預留足夠空間。  
調優口訣：  
- 讓新生代足夠大，避免過早晉升；  
- 讓老年代留有余量，防止 Full GC。

五、Off-Heap：零拷貝與 DirectBuffer 的魔法  

1. Network Buffers  
   Netty Channel 讀寫共用，每個 Slot 默認 32 KB，總大小 = Slot × Subtask × Parallelism。  
2. Managed Memory  
   RocksDB StateBackend 的 Block Cache、Write Buffer，由 Flink 統一管理。  
3. Direct Memory  
   用戶自定義的 DirectByteBuffer，需通過 `-XX:MaxDirectMemorySize` 限制。  
關鍵陷阱：DirectBuffer 泄漏不會觸發 Java GC，必須用 `jcmd` 或 `jmap` 診斷。

六、網絡內存：背壓的第一道防線  

Flink 把網絡傳輸抽象為“ResultPartition + InputChannel”，每個緩沖區大小可調節：  
- 緩沖區過多 → 內存浪費；  
- 緩沖區過少 → 背壓蔓延。  
經驗公式：  
網絡內存 ≈ 并行度 × Slot 數 × 32 KB × 2（發送 + 接收）。  
當作業出現 `InsufficientNetworkBufferException` 時，優先擴容網絡內存而非堆內存。

七、狀態后端：堆內 VS 堆外的抉擇  

1. FsStateBackend  
   狀態快照寫到文件系統，運行時全在堆內，GC 壓力大。  
2. MemoryStateBackend  
   純內存，速度快，但受堆大小限制，適合調試。  
3. RocksDBStateBackend  
   狀態在本地 RocksDB，運行時占用大量 DirectBuffer，需單獨規劃 `state.backend.rocksdb.memory.managed` 參數。  
選型原則：  
- 小狀態 + 低延遲 → Memory；  
- 大狀態 + 高吞吐 → RocksDB；  
- 容災重要 → Fs。

八、GC 策略：G1、ZGC、Epsilon 的三國殺  

1. G1（默認）  
   分區回收，停頓可預測，適合 8–64 GB 堆。  
2. ZGC  
   超大堆（>100 GB）低停頓，實驗特性，需 JDK 11+。  
3. Epsilon  
   無 GC 測試專用，生產慎用。  
調優建議：  
- `-XX:MaxGCPauseMillis=200` 控制停頓；  
- `-XX:+UnlockExperimentalVMOptions` 開啟 ZGC；  
- GC 日志 + Prometheus JMX Exporter 實時可視化。

九、背壓與 OOM：內存告警的兩大信號  

1. 背壓  
   網絡緩沖區滿 → Task 反壓 → Job 整體降速。  
2. OOM  
   DirectBuffer 泄漏 → JVM 崩潰；  
   老年代溢出 → Full GC 雪崩。  
排查套路：  
- 先看背壓指標，定位瓶頸算子；  
- 再查 GC 日志，判斷內存泄漏；  
- 最后用 `jcmd` 導出堆外內存直方圖。

十、容器化場景：內存限制與彈性  

1. 容器內存 = Heap + Off-Heap + Network + Framework  
2. 典型配比：  
   - 容器 8 GB → Heap 4.5 GB，Network 1 GB，RocksDB 2 GB，Framework 0.5 GB  
3. 彈性策略  
   - 橫向擴容：Slot 數 ↑，網絡內存 ↑  
   - 縱向擴容：單 Slot 內存 ↑，GC 停頓 ↑  
4. 混部注意  
   與 Kafka、ZooKeeper 同機部署時，需預留 cgroup 內存限制。

十一、監控與告警：讓內存說話  

- 指標：HeapUsed, OldGenUsed, DirectBuffer, GC Pause  
- 告警：OldGen >85 % 連續 5 min 觸發擴容  
- 工具：Prometheus + Grafana + JMX Exporter  
- 自愈：腳本自動調參或重啟作業

十二、故障演練：從內存泄漏到自愈  

場景 1：RocksDB Block Cache 泄漏  
- 現象：DirectBuffer 暴漲，作業背壓。  
- 處置：增大 managed memory，降低 cache 比例。  
場景 2：老年代晉升失敗  
- 現象：Full GC 2 s，TaskManager 重啟。  
- 處置：調大 OldGen，降低并行度。

十三、每日一練：親手做一次內存診斷  

1. 準備：用 Data Gen 造 1 GB 狀態數據。  
2. 監控：觀察 Heap、DirectBuffer、GC 停頓。  
3. 調優：調整網絡內存、狀態后端。  
4. 復盤：記錄參數與結果寫進知識庫。

十四、結語：把內存當業務  

Flink 的內存模型不是“調幾個 JVM 參數”那么簡單，而是把“計算、網絡、狀態”三種負載統一規劃。  
當你下一次面對“作業慢、節點掛、OOM”時，請記住：  
不是內存不夠，而是模型沒對齊。  
把本文的四分法、九步調優、十二項指標寫進設計文檔，  
讓流式計算的每一次心跳都穩健、可控、可觀測。