背景

1）java對(duì)象的存儲(chǔ)密度比較低，對(duì)象主要包含 對(duì)象頭，對(duì)象數(shù)據(jù)，對(duì)齊填充。 其中對(duì)齊填充是沒(méi)用的，純粹是為了讓對(duì)象的大小到達(dá)8的倍數(shù)

2）Full GC非常影響性能，對(duì)大數(shù)據(jù)量的計(jì)算來(lái)說(shuō)，fullGC可能會(huì)持續(xù)很久(秒級(jí)甚至分鐘級(jí))

3）OOM導(dǎo)致JVM崩潰，因?yàn)槭谴髷?shù)據(jù)計(jì)算，很有可能會(huì)分配出大的對(duì)象。

4）緩存未命中，CPU在進(jìn)行計(jì)算時(shí)，會(huì)先從CPU的緩存中抓取數(shù)據(jù)，但是jvm堆上的內(nèi)存不是連續(xù)的，會(huì)導(dǎo)致CPU緩存不命中，CPU空轉(zhuǎn)，影響效率。

5）傳輸過(guò)程，要序列化和反序列化

解決辦法

Flink將對(duì)象存儲(chǔ)在堆外內(nèi)存中，或者存在 memorySegment上

memorySegment：?

1 翻譯為內(nèi)存段，存儲(chǔ)序列化后的對(duì)象

2?它是一段固定長(zhǎng)度的內(nèi)存（大小為32KB）

3 是FLink中最小的內(nèi)存分配單元

4 讀寫非常高效，很多算子可以直接操作其二進(jìn)制數(shù)據(jù)，不需要反序列化

5 Java本身自帶的序列化和反序列化的功能，但是輔助信息占用空間比較大，在序列化對(duì)象時(shí)記錄了過(guò)多的類信息。

Flink實(shí)現(xiàn)了自己的序列化框架，使用TypeInformation表示每種數(shù)據(jù)類型，所以可以只保存一份對(duì)象Schema信息，節(jié)省存儲(chǔ)空間。又因?yàn)閷?duì)象類型固定，所以可以通過(guò)偏移量存取。

JobManager 的內(nèi)存模型

jobmanager.heap.size:1024m

jobmanager.memory.process.size:1600m

主要包含 堆內(nèi)存和非堆內(nèi)存，相對(duì)比較簡(jiǎn)單一些。

TaskManager的內(nèi)存模型

關(guān)于rocksDb內(nèi)存管理：

由于rocksdb分配的是堆外內(nèi)存，內(nèi)存量理論上不受jvm控制。于是產(chǎn)生問(wèn)題，如果進(jìn)程的內(nèi)存使用超過(guò)容器限定的量，就會(huì)被資源管理器殺死。