支撐百萬級併發，Netty如何實現高性能內存管理

Netty做爲一款高性能網絡應用程序框架，實現了一套高性能內存管理機制

經過學習其中的實現原理、算法、併發設計，有利於咱們寫出更優雅、更高性能的代碼；當使用Netty時碰到內存方面的問題時，也能夠更高效定位排查出來

本文基於Netty4.1.43.Final介紹其中的內存管理機制

ByteBuf分類

Netty使用ByteBuf對象做爲數據容器，進行I/O讀寫操做，Netty的內存管理也是圍繞着ByteBuf對象高效地分配和釋放

當討論ByteBuf對象管理，主要從如下方面進行分類：

• Pooled 和 Unpooled

Unpooled，非池化內存每次分配時直接調用系統 API 向操做系統申請ByteBuf須要的一樣大小內存，用完後經過系統調用進行釋放 Pooled，池化內存分配時基於預分配的一整塊大內存，取其中的部分封裝成ByteBuf提供使用，用完後回收到內存池中

tips: Netty4默認使用Pooled的方式，可經過參數-Dio.netty.allocator.type=unpooled或pooled進行設置

• Heap 和 Direct Heap，指ByteBuf關聯的內存JVM堆內分配，分配的內存受GC 管理 Direct，指ByteBuf關聯的內存在JVM堆外分配，分配的內存不受GC管理，須要經過系統調用實現申請和釋放，底層基於Java NIO的DirectByteBuffer對象

note： 使用堆外內存的優點在於，Java進行I/O操做時，須要傳入數據所在緩衝區起始地址和長度，因爲GC的存在，對象在堆中的位置每每會發生移動，致使對象地址變化，系統調用出錯。爲避免這種狀況，當基於堆內存進行I/O系統調用時，須要將內存拷貝到堆外，而直接基於堆外內存進行I/O操做的話，能夠節省該拷貝成本

池化(Pooled)對象管理

非池化對象(Unpooled)，使用和釋放對象僅須要調用底層接口實現，池化對象實現則複雜得多，能夠帶着如下問題進行研究：

• 內存池管理算法是如何實現高效內存分配釋放，減小內存碎片
• 高負載下內存池不斷申請/釋放，如何實現彈性伸縮
• 內存池做爲全局數據，在多線程環境下如何減小鎖競爭

1 算法設計

1.1 總體原理

Netty先向系統申請一整塊連續內存，稱爲chunk，默認大小chunkSize = 16Mb，經過PoolChunk對象包裝。爲了更細粒度的管理，Netty將chunk進一步拆分爲page，默認每一個chunk包含2048個page(pageSize = 8Kb)

不一樣大小池化內存對象的分配策略不一樣，下面首先介紹申請內存大小在**(pageSize/2, chunkSize]**區間範圍內的池化對象的分配原理，其餘大對象和小對象的分配原理後面再介紹。在同一個chunk中，Netty將page按照不一樣粒度進行多層分組管理：

• 第1層，分組大小size = 1*pageSize，一共有2048個組
• 第2層，分組大小size = 2*pageSize，一共有1024個組
• 第3層，分組大小size = 4*pageSize，一共有512個組 ...

當請求分配內存時，將請求分配的內存數向上取值到最接近的分組大小，在該分組大小的相應層級中從左至右尋找空閒分組 例如請求分配內存對象爲1.5 *pageSize，向上取值到分組大小2 * pageSize，在該層分組中找到徹底空閒的一組內存進行分配，以下圖：

當分組大小2 * pageSize的內存分配出去後，爲了方便下次內存分配，分組被標記爲所有已使用(圖中紅色標記)，向上更粗粒度的內存分組被標記爲部分已使用(圖中黃色標記)

1.2 算法結構

Netty基於平衡樹實現上面提到的不一樣粒度的多層分組管理

當須要建立一個給定大小的ByteBuf，算法須要在PoolChunk中大小爲chunkSize的內存中，找到第一個可以容納申請分配內存的位置

爲了方便快速查找chunk中能容納請求內存的位置，算法構建一個基於byte數組(memoryMap)存儲的徹底平衡樹，該平衡樹的多個層級深度，就是前面介紹的按照不一樣粒度對chunk進行多層分組：

樹的深度depth從0開始計算，各層節點數，每一個節點對應的內存大小以下：

depth = 0， 1 node，nodeSize = chunkSize
depth = 1， 2 nodes，nodeSize = chunkSize/2
...
depth = d， 2^d nodes， nodeSize = chunkSize/(2^d)
...
depth = maxOrder， 2^maxOrder nodes， nodeSize = chunkSize/2^{maxOrder} = pageSize
複製代碼

樹的最大深度爲maxOrder(最大階，默認值11)，經過這棵樹，算法在chunk中的查找就能夠轉換爲：

當申請分配大小爲chunkSize/2^k的內存，在平衡樹高度爲k的層級中，從左到右搜索第一個空閒節點

數組的使用域從index = 1開始，將平衡樹按照層次順序依次存儲在數組中，depth = n的第1個節點保存在memoryMap[2^n] 中，第2個節點保存在memoryMap[2^n+1]中，以此類推(下圖表明已分配chunkSize/2)

能夠根據memoryMap[id]的值得出節點的使用狀況，memoryMap[id]值越大，剩餘的可用內存越少

• memoryMap[id] = depth_of_id：id節點空閒， 初始狀態，depth_of_id的值表明id節點在樹中的深度
• memoryMap[id] = maxOrder + 1：id節點所有已使用，節點內存已徹底分配，沒有一個子節點空閒
• depth_of_id < memoryMap[id] < maxOrder + 1：id節點部分已使用，memoryMap[id] 的值 x，表明id的子節點中，第一個空閒節點位於深度x，在深度[depth_of_id, x)的範圍內沒有任何空閒節點

1.3 申請/釋放內存

當申請分配內存，會首先將請求分配的內存大小歸一化(向上取值)，經過PoolArena#normalizeCapacity()方法，取最近的2的冪的值​，例如8000byte歸一化爲8192byte( chunkSize/2^11 )，8193byte歸一化爲16384byte(chunkSize/2^10)

處理內存申請的算法在PoolChunk#allocateRun方法中，當分配已歸一化處理後大小爲chunkSize/2^d的內存，即須要在depth = d的層級中找到第一塊空閒內存，算法從根節點開始遍歷 (根節點depth = 0， id = 1)，具體步驟以下：

• 步驟1 判斷是否當前節點值memoryMap[id] > d，或depth_of_id > d 若是是，則沒法從該chunk分配內存，查找結束

• 步驟2 判斷是否節點值memoryMap[id] == d，且depth_of_id <= d 若是是，當前節點是depth = d的空閒內存，查找結束，更新當前節點值爲memoryMap[id] = max_order + 1，表明節點已使用，並遍歷當前節點的全部祖先節點，更新節點值爲各自的左右子節點值的最小值；若是否，執行步驟3

• 步驟3 判斷是否當前節點值memoryMap[id] <= d，且depth_of_id <= d 若是是，則空閒節點在當前節點的子節點中，則先判斷左子節點memoryMap[2 * id] <=d(判斷左子節點是否可分配)，若是成立，則當前節點更新爲左子節點，不然更新爲右子節點，而後重複步驟1, 2

參考示例以下圖，申請分配了chunkSize/2的內存

note：圖中雖然index = 2的子節點memoryMap[id] = depth_of_id，但實際上節點內存已分配，由於算法是從上往下開始遍歷，因此在實際處理中，節點分配內存後僅更新祖先節點的值，並無更新子節點的值

釋放內存時，根據申請內存返回的id，將 memoryMap[id]更新爲depth_of_id，同時設置id節點的祖先節點值爲各自左右節點的最小值

1.4 巨型對象內存管理

對於申請分配大小超過chunkSize的巨型對象(huge)，Netty採用的是非池化管理策略，在每次請求分配內存時單首創建特殊的非池化PoolChunk對象進行管理，內部memoryMap爲null，當對象內存釋放時整個Chunk內存釋放，相應內存申請邏輯在PoolArena#allocateHuge()方法中，釋放邏輯在PoolArena#destroyChunk()方法中

1.5 小對象內存管理

當請求對象的大小reqCapacity <= 496，歸一化計算後方式是向上取最近的16的倍數，例如15規整爲1六、40規整爲4八、490規整爲496，規整後的大小(normalizedCapacity)小於pageSize的小對象可分爲2類： 微型對象(tiny)：規整後爲16的整倍數，如1六、3二、4八、...、496，一共31種規格 小型對象(small)：規整後爲2的冪的，有5十二、102四、204八、4096，一共4種規格

這些小對象直接分配一個page會形成浪費，在page中進行平衡樹的標記又額外消耗更多空間，所以Netty的實現是：先PoolChunk中申請空閒page，同一個page分爲相同大小規格的小內存進行存儲

這些page用PoolSubpage對象進行封裝，PoolSubpage內部有記錄內存規格大小(elemSize)、可用內存數量(numAvail)和各個小內存的使用狀況，經過long[]類型的bitmap相應bit值0或1，來記錄內存是否已使用

note：應該有讀者注意到，Netty申請池化內存進行歸一化處理後的值更大了，例如1025byte會歸一化爲2048byte，8193byte歸一化爲16384byte，這樣是否是形成了一些浪費？能夠理解爲是一種取捨，經過歸一化處理，使池化內存分配大小規格化，大大方便內存申請和內存、內存複用，提升效率

2 彈性伸縮

前面的算法原理部分介紹了Netty如何實現內存塊的申請和釋放，單個chunk比較容量有限，如何管理多個chunk，構建成可以彈性伸縮內存池？

2.1 PoolChunk管理

爲了解決單個PoolChunk容量有限的問題，Netty將多個PoolChunk組成鏈表一塊兒管理，而後用PoolChunkList對象持有鏈表的head

將全部PoolChunk組成一個鏈表的話，進行遍歷查找管理效率較低，所以Netty設計了PoolArena對象(arena中文是舞臺、場所)，實現對多個PoolChunkList、PoolSubpage的管理，線程安全控制、對外提供內存分配、釋放的服務

PoolArena內部持有6個PoolChunkList，各個PoolChunkList持有的PoolChunk的使用率區間不一樣：

// 容納使用率 (0,25%) 的PoolChunk
private final PoolChunkList<T> qInit;
// [1%,50%) 
private final PoolChunkList<T> q000;
// [25%, 75%) 
private final PoolChunkList<T> q025;
// [50%, 100%) 
private final PoolChunkList<T> q050;
// [75%, 100%) 
private final PoolChunkList<T> q075;
// 100% 
private final PoolChunkList<T> q100;
複製代碼

6個PoolChunkList對象組成雙向鏈表，當PoolChunk內存分配、釋放，致使使用率變化，須要判斷PoolChunk是否超過所在PoolChunkList的限定使用率範圍，若是超出了，須要沿着6個PoolChunkList的雙向鏈表找到新的合適PoolChunkList，成爲新的head；一樣的，當新建PoolChunk並分配完內存，該PoolChunk也須要按照上面邏輯放入合適的PoolChunkList中

分配歸一化內存normCapacity(大小範圍在[pageSize, chunkSize]) 具體處理以下：

• 按順序依次訪問q050、q02五、q000、qInit、q075，遍歷PoolChunkList內PoolChunk鏈表判斷是否有PoolChunk能分配內存
• 若是上面5個PoolChunkList有任意一個PoolChunk內存分配成功，PoolChunk使用率發生變動，從新檢查並放入合適的PoolChunkList中，結束
• 不然新建一個PoolChunk，分配內存，放入合適的PoolChunkList中(PoolChunkList擴容)

**note：**能夠看到分配內存依次優先在q050 -> q025 -> q000 -> qInit -> q075的PoolChunkList的內分配，這樣作的好處是，使分配後各個區間內存使用率更多處於[75,100)的區間範圍內，提升PoolChunk內存使用率的同時也兼顧效率，減小在PoolChunkList中PoolChunk的遍歷

當PoolChunk內存釋放，一樣PoolChunk使用率發生變動，從新檢查並放入合適的PoolChunkList中，若是釋放後PoolChunk內存使用率爲0，則從PoolChunkList中移除，釋放掉這部分空間，避免在高峯的時候申請過內存一直緩存在池中(PoolChunkList縮容)

PoolChunkList的額定使用率區間存在交叉，這樣設計是由於若是基於一個臨界值的話，當PoolChunk內存申請釋放後的內存使用率在臨界值上下徘徊的話，會致使在PoolChunkList鏈表先後來回移動

2.2 PoolSubpage管理

PoolArena內部持有2個PoolSubpage數組，分別存儲tiny和small規格類型的PoolSubpage：

// 數組長度32，實際使用域從index = 1開始，對應31種tiny規格PoolSubpage
private final PoolSubpage<T>[] tinySubpagePools;
// 數組長度4，對應4種small規格PoolSubpage
private final PoolSubpage<T>[] smallSubpagePools;
複製代碼

相同規格大小(elemSize)的PoolSubpage組成鏈表，不一樣規格的PoolSubpage鏈表的head則分別保存在tinySubpagePools 或者 smallSubpagePools數組中，以下圖：

當須要分配小內存對象到PoolSubpage中時，根據歸一化後的大小，計算出須要訪問的PoolSubpage鏈表在tinySubpagePools和smallSubpagePools數組的下標，訪問鏈表中的PoolSubpage的申請內存分配，若是訪問到的PoolSubpage鏈表節點數爲0，則建立新的PoolSubpage分配內存而後加入鏈表

PoolSubpage鏈表存儲的PoolSubpage都是已分配部份內存，當內存所有分配完或者內存所有釋放完的PoolSubpage會移出鏈表，減小沒必要要的鏈表節點；當PoolSubpage內存所有分配完後再釋放部份內存，會從新將加入鏈表

PoolArean內存池彈性伸縮可用下圖總結：

3 併發設計

內存分配釋放不可避免地會遇到多線程併發場景，不管是PoolChunk的平衡樹標記或者PoolSubpage的bitmap標記都是多線程不安全，如何在線程安全的前提下儘可能提高併發性能？

首先，爲了減小線程間的競爭，Netty會提早建立多個PoolArena(默認生成數量 = 2 * CPU核心數)，當線程首次請求池化內存分配，會找被最少線程持有的PoolArena，並保存線程局部變量PoolThreadCache中，實現線程與PoolArena的關聯綁定(PoolThreadLocalCache#initialValue()方法)

**note：**Java自帶的ThreadLocal實現線程局部變量的原理是：基於Thread的ThreadLocalMap類型成員變量，該變量中map的key爲ThreadLocal，value-爲須要自定義的線程局部變量值。調用ThreadLocal#get()方法時，會經過Thread.currentThread()獲取當前線程訪問Thread的ThreadLocalMap中的值

Netty設計了ThreadLocal的更高性能替代類：FastThreadLocal，須要配套繼承Thread的類FastThreadLocalThread一塊兒使用，基本原理是將原來Thead的基於ThreadLocalMap存儲局部變量，擴展爲能更快速訪問的數組進行存儲(Object[] indexedVariables)，每一個FastThreadLocal內部維護了一個全局原子自增的int類型的數組index

此外，Netty還設計了緩存機制提高併發性能：當請求對象內存釋放，PoolArena並無立刻釋放，而是先嚐試將該內存關聯的PoolChunk和chunk中的偏移位置(handler變量)等信息存入PoolThreadLocalCache中的固定大小緩存隊列中(若是緩存隊列滿了則立刻釋放內存)； 當請求內存分配，PoolArena會優先訪問PoolThreadLocalCache的緩存隊列中是否有緩存內存可用，若是有，則直接分配，提升分配效率

總結

Netty池化內存管理的設計借鑑了Facebook的jemalloc，同時也與Linux內存分配算法Buddy算法和Slab算法也有類似之處，不少分佈式系統、框架的設計均可以在操做系統的設計中找到原型，學習底層原理是頗有價值的

下一篇，介紹Netty堆外內存泄漏問題的排查

參考

《scalable memory allocation using jemalloc —— Facebook》 engineering.fb.com/core-data/s…

《Netty入門與實戰：仿寫微信 IM 即時通信系統》 juejin.cn/book/684473…

更多精彩，歡迎關注公衆號 分佈式系統架構