背景
1）java對象的存儲密度比較低，對象主要包含 對象頭，對象數(shù)據(jù)现横，對齊填充。 其中對齊填充是沒用的什湘，純粹是為了讓對象的大小到達8的倍數(shù)
2）Full GC非常影響性能长赞，對大數(shù)據(jù)量的計算來說，fullGC可能會持續(xù)很久(秒級甚至分鐘級)
3）OOM導(dǎo)致JVM崩潰闽撤，因為是大數(shù)據(jù)計算得哆，很有可能會分配出大的對象。
4）緩存未命中哟旗，CPU在進行計算時贩据，會先從CPU的緩存中抓取數(shù)據(jù)，但是jvm堆上的內(nèi)存不是連續(xù)的闸餐，會導(dǎo)致CPU緩存不命中饱亮，CPU空轉(zhuǎn)，影響效率舍沙。
5）傳輸過程近上，要序列化和反序列化
解決辦法
Flink將對象存儲在堆外內(nèi)存中，或者存在 memorySegment上
memorySegment：?
1 翻譯為內(nèi)存段拂铡，存儲序列化后的對象
2?它是一段固定長度的內(nèi)存（大小為32KB）
3 是FLink中最小的內(nèi)存分配單元
4 讀寫非常高效壹无，很多算子可以直接操作其二進制數(shù)據(jù)葱绒，不需要反序列化
5 Java本身自帶的序列化和反序列化的功能，但是輔助信息占用空間比較大斗锭，在序列化對象時記錄了過多的類信息地淀。
Flink實現(xiàn)了自己的序列化框架，使用TypeInformation表示每種數(shù)據(jù)類型岖是，所以可以只保存一份對象Schema信息帮毁，節(jié)省存儲空間。又因為對象類型固定豺撑，所以可以通過偏移量存取烈疚。
JobManager 的內(nèi)存模型
jobmanager.heap.size:1024m
jobmanager.memory.process.size:1600m
主要包含 堆內(nèi)存和非堆內(nèi)存，相對比較簡單一些前硫。
TaskManager的內(nèi)存模型
關(guān)于rocksDb內(nèi)存管理：
由于rocksdb分配的是堆外內(nèi)存胞得，內(nèi)存量理論上不受jvm控制。于是產(chǎn)生問題屹电，如果進程的內(nèi)存使用超過容器限定的量阶剑，就會被資源管理器殺死。
