5 一文看完flink的内存管理

背景

1）java对象的存储密度比较低，对象主要包含 对象头，对象数据，对齐填充。 其中对齐填充是没用的，纯粹是为了让对象的大小到达8的倍数

2）Full GC非常影响性能，对大数据量的计算来说，fullGC可能会持续很久(秒级甚至分钟级)

3）OOM导致JVM崩溃，因为是大数据计算，很有可能会分配出大的对象。

4）缓存未命中，CPU在进行计算时，会先从CPU的缓存中抓取数据，但是jvm堆上的内存不是连续的，会导致CPU缓存不命中，CPU空转，影响效率。

5）传输过程，要序列化和反序列化

解决办法

Flink将对象存储在堆外内存中，或者存在 memorySegment上

memorySegment： 

1 翻译为内存段，存储序列化后的对象

2 它是一段固定长度的内存（大小为32KB）

3 是FLink中最小的内存分配单元

4 读写非常高效，很多算子可以直接操作其二进制数据，不需要反序列化

5 Java本身自带的序列化和反序列化的功能，但是辅助信息占用空间比较大，在序列化对象时记录了过多的类信息。

Flink实现了自己的序列化框架，使用TypeInformation表示每种数据类型，所以可以只保存一份对象Schema信息，节省存储空间。又因为对象类型固定，所以可以通过偏移量存取。

JobManager 的内存模型

jobmanager.heap.size:1024m

jobmanager.memory.process.size:1600m

主要包含 堆内存和非堆内存，相对比较简单一些。

TaskManager的内存模型

关于rocksDb内存管理：

由于rocksdb分配的是堆外内存，内存量理论上不受jvm控制。于是产生问题，如果进程的内存使用超过容器限定的量，就会被资源管理器杀死。