1. 內存設置 1.1 TaskManager 內存模型 TaskManager的內存模型如下圖所示(1.10之后版本內存模型)： Flink使用了堆上內存和堆外內存。 Flink 框架內存使用了堆外內存和堆外內存，不計入slot資源。 Task執行的內存使用了堆上內存和堆外內存。 網(wǎng)絡(luò )緩沖內存：網(wǎng)絡(luò )數據交換所使用的內存大小，如網(wǎng)絡(luò )數據交換緩沖區。 框架堆外內存、Task堆外內存、網(wǎng)絡(luò )緩沖內存都在堆外的直接內存里面。 管理內存：Flink堆外內存的管理，用于管理排序，hash表，緩沖中間結果以及RocksDb 狀態(tài)后端的本地內存。 JVM特有內存：JVM本身占用的內存，包括元數據和執行開(kāi)銷(xiāo)。 Flink 使用內存 = 框架堆內和堆外內存 + Task堆內和堆外內存 + 網(wǎng)絡(luò )緩沖內存 + 管理內存。 進(jìn)程內存 - Flink 內存 + JVM特有內存 1.1.1 JVM特有內存詳解 JVM特定內存： JVM本身使用的內存，包含JVM的metaspace和over-head JVM的metaspace：JVM 元空間。taskmanager.memory.jvm-meta-sp....

跳躍表將有序鏈表中的部分節點(diǎn)分層，每一層都是一個(gè)有序鏈表。在查找時(shí)優(yōu)先從最高層開(kāi)始向后查找，當到達某節點(diǎn)時(shí)，如果next節點(diǎn)值大于要查找的值或next指針指向NULL，則從當前節點(diǎn)下降一層繼續向后查找，這樣可以有效提升效率。如下圖所示使用跳表查找51的路徑為1->21->41->51需要查找4次。如果使用鏈表查找路徑為1->11->21->31->41->51需要查找6次，效率明顯提升了，當數據量較大是提升更為明顯。

壓縮列表ziplist本質(zhì)上就是一個(gè)字節數組，是Redis為了節約內存而設計的一種線(xiàn)性數據結構，可以包含多個(gè)元素，每個(gè)元素可以是一個(gè)字節數組或一個(gè)整數。 Redis的有序集合、散列和列表都直接或者間接使用了壓縮列表。當有序集合或散列表的元素個(gè)數比較少，且元素都是短字符串時(shí)，Redis便使用壓縮列表作為其底層數據存儲結構。列表使用快速鏈表（quicklist）數據結構存儲，而快速鏈表就是雙向鏈表與壓縮列表的組合。 ziplist 壓縮列表是一個(gè)特殊編碼的雙端鏈表（內存上連續），為了盡可能節省內存而設計的。ziplist 可以存儲字符串或者整數值，其中整數被編碼保存為實(shí)際的整數，而不是字符數組。ziplist 支持 O(1) 的時(shí)間復雜度在列表的兩端進(jìn)行 push 和 pop 操作。然而因為這些操作都需要對整個(gè) ziplist 進(jìn)行內存重分配（因為是一塊連續的內存），所以操作的實(shí)際復雜度和 ziplist 占用的內存大小有關(guān)。在 7.0 版本里，ziplist 已經(jīng)全面被 listpack 替換了（主要是因為連鎖更新較影響性能）