Netty作為一款高性能網(wǎng)絡(luò)應(yīng)用程序框架，實(shí)現(xiàn)了一套高性能內(nèi)存管理機(jī)制。

通過學(xué)習(xí)其中的實(shí)現(xiàn)原理、算法、并發(fā)設(shè)計(jì)，有利于我們寫出更優(yōu)雅、更高性能的代碼;當(dāng)使用Netty時(shí)碰到內(nèi)存方面的問題時(shí)，也可以更高效定位排查出來。

[[287314]]

本文基于Netty4.1.43.Final介紹其中的內(nèi)存管理機(jī)制

ByteBuf分類

Netty使用ByteBuf對(duì)象作為數(shù)據(jù)容器，進(jìn)行I/O讀寫操作，Netty的內(nèi)存管理也是圍繞著ByteBuf對(duì)象高效地分配和釋放

當(dāng)討論ByteBuf對(duì)象管理，主要從以下方面進(jìn)行分類：

• Pooled 和 Unpooled

Unpooled，非池化內(nèi)存每次分配時(shí)直接調(diào)用系統(tǒng) API 向操作系統(tǒng)申請(qǐng)ByteBuf需要的同樣大小內(nèi)存，用完后通過系統(tǒng)調(diào)用進(jìn)行釋放Pooled，池化內(nèi)存分配時(shí)基于預(yù)分配的一整塊大內(nèi)存，取其中的部分封裝成ByteBuf提供使用，用完后回收到內(nèi)存池中。

tips: Netty4默認(rèn)使用Pooled的方式，可通過參數(shù)-Dio.netty.allocator.type=unpooled或pooled進(jìn)行設(shè)置

• Heap 和 Direct

Heap，指ByteBuf關(guān)聯(lián)的內(nèi)存JVM堆內(nèi)分配，分配的內(nèi)存受GC 管理

Direct，指ByteBuf關(guān)聯(lián)的內(nèi)存在JVM堆外分配，分配的內(nèi)存不受GC管理，需要通過系統(tǒng)調(diào)用實(shí)現(xiàn)申請(qǐng)和釋放，底層基于Java NIO的DirectByteBuffer對(duì)象

note： 使用堆外內(nèi)存的優(yōu)勢(shì)在于，Java進(jìn)行I/O操作時(shí)，需要傳入數(shù)據(jù)所在緩沖區(qū)起始地址和長度，由于GC的存在，對(duì)象在堆中的位置往往會(huì)發(fā)生移動(dòng)，導(dǎo)致對(duì)象地址變化，系統(tǒng)調(diào)用出錯(cuò)。為避免這種情況，當(dāng)基于堆內(nèi)存進(jìn)行I/O系統(tǒng)調(diào)用時(shí)，需要將內(nèi)存拷貝到堆外，而直接基于堆外內(nèi)存進(jìn)行I/O操作的話，可以節(jié)省該拷貝成本

池化(Pooled)對(duì)象管理

非池化對(duì)象(Unpooled)，使用和釋放對(duì)象僅需要調(diào)用底層接口實(shí)現(xiàn)，池化對(duì)象實(shí)現(xiàn)則復(fù)雜得多，可以帶著以下問題進(jìn)行研究：

• 內(nèi)存池管理算法是如何實(shí)現(xiàn)高效內(nèi)存分配釋放，減少內(nèi)存碎片
• 高負(fù)載下內(nèi)存池不斷申請(qǐng)/釋放，如何實(shí)現(xiàn)彈性伸縮
• 內(nèi)存池作為全局?jǐn)?shù)據(jù)，在多線程環(huán)境下如何減少鎖競(jìng)爭

1 算法設(shè)計(jì)

1.1 整體原理

Netty先向系統(tǒng)申請(qǐng)一整塊連續(xù)內(nèi)存，稱為chunk，默認(rèn)大小chunkSize = 16Mb，通過PoolChunk對(duì)象包裝。為了更細(xì)粒度的管理，Netty將chunk進(jìn)一步拆分為page，默認(rèn)每個(gè)chunk包含2048個(gè)page(pageSize = 8Kb)

不同大小池化內(nèi)存對(duì)象的分配策略不同，下面首先介紹申請(qǐng)內(nèi)存大小在(pageSize/2, chunkSize]區(qū)間范圍內(nèi)的池化對(duì)象的分配原理，其他大對(duì)象和小對(duì)象的分配原理后面再介紹。在同一個(gè)chunk中，Netty將page按照不同粒度進(jìn)行多層分組管理：

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

...

當(dāng)請(qǐng)求分配內(nèi)存時(shí)，將請(qǐng)求分配的內(nèi)存數(shù)向上取值到最接近的分組大小，在該分組大小的相應(yīng)層級(jí)中從左至右尋找空閑分組例如請(qǐng)求分配內(nèi)存對(duì)象為1.5 pageSize，向上取值到分組大小2 pageSize，在該層分組中找到完全空閑的一組內(nèi)存進(jìn)行分配，如下圖：

當(dāng)分組大小2 pageSize的內(nèi)存分配出去后，為了方便下次內(nèi)存分配，分組被標(biāo)記為全部已使用(圖中紅色標(biāo)記)，向上更粗粒度的內(nèi)存分組被標(biāo)記為部分已使用*(圖中黃色標(biāo)記)

1.2 算法結(jié)構(gòu)

Netty基于平衡樹實(shí)現(xiàn)上面提到的不同粒度的多層分組管理。

當(dāng)需要?jiǎng)?chuàng)建一個(gè)給定大小的ByteBuf，算法需要在PoolChunk中大小為chunkSize的內(nèi)存中，找到第一個(gè)能夠容納申請(qǐng)分配內(nèi)存的位置。

為了方便快速查找chunk中能容納請(qǐng)求內(nèi)存的位置，算法構(gòu)建一個(gè)基于byte數(shù)組(memoryMap)存儲(chǔ)的完全平衡樹，該平衡樹的多個(gè)層級(jí)深度，就是前面介紹的按照不同粒度對(duì)chunk進(jìn)行多層分組：

樹的深度depth從0開始計(jì)算，各層節(jié)點(diǎn)數(shù)，每個(gè)節(jié)點(diǎn)對(duì)應(yīng)的內(nèi)存大小如下：

depth = 0， 1 node，nodeSize = chunkSizedepth = 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(最大階，默認(rèn)值11)，通過這棵樹，算法在chunk中的查找就可以轉(zhuǎn)換為：

當(dāng)申請(qǐng)分配大小為chunkSize/2^k的內(nèi)存，在平衡樹高度為k的層級(jí)中，從左到右搜索第一個(gè)空閑節(jié)點(diǎn)

數(shù)組的使用域從index = 1開始，將平衡樹按照層次順序依次存儲(chǔ)在數(shù)組中，depth = n的第1個(gè)節(jié)點(diǎn)保存在memoryMap[2^n] 中，第2個(gè)節(jié)點(diǎn)保存在memoryMap[2^n+1]中，以此類推。

可以根據(jù)memoryMap[id]的值得出節(jié)點(diǎn)的使用情況，memoryMap[id]值越大，剩余的可用內(nèi)存越少

• memoryMap[id] = depth_of_id：**id節(jié)點(diǎn)空閑**， 初始狀態(tài)，depth_of_id的值代表id節(jié)點(diǎn)在樹中的深度
• memoryMap[id] = maxOrder + 1：**id節(jié)點(diǎn)全部已使用**，節(jié)點(diǎn)內(nèi)存已完全分配，沒有一個(gè)子節(jié)點(diǎn)空閑
• depthofid < memoryMap[id] < maxOrder + 1：**id節(jié)點(diǎn)部分已使用**，memoryMap[id] 的值 x，代表**id的子節(jié)點(diǎn)中，第一個(gè)空閑節(jié)點(diǎn)位于深度x，在深度[depth_of_id, x)的范圍內(nèi)沒有任何空閑節(jié)點(diǎn)**

1.3 申請(qǐng)/釋放內(nèi)存

當(dāng)申請(qǐng)分配內(nèi)存，會(huì)首先將請(qǐng)求分配的內(nèi)存大小歸一化(向上取值)，通過PoolArena#normalizeCapacity()方法，取最近的2的冪的值​，例如8000byte歸一化為8192byte( chunkSize/2^11 )，8193byte歸一化為16384byte(chunkSize/2^10)

處理內(nèi)存申請(qǐng)的算法在PoolChunk#allocateRun方法中，當(dāng)分配已歸一化處理后大小為chunkSize/2^d的內(nèi)存，即需要在depth = d的層級(jí)中找到第一塊空閑內(nèi)存，算法從根節(jié)點(diǎn)開始遍歷 (根節(jié)點(diǎn)depth = 0， id = 1)，具體步驟如下：

• 步驟1 判斷是否當(dāng)前節(jié)點(diǎn)值memoryMap[id] > d

如果是，則無法從該chunk分配內(nèi)存，查找結(jié)束

• 步驟2 判斷是否節(jié)點(diǎn)值memoryMap[id] == d，且depth_of_id == h

如果是，當(dāng)前節(jié)點(diǎn)是depth = d的空閑內(nèi)存，查找結(jié)束，更新當(dāng)前節(jié)點(diǎn)值為memoryMap[id] = max_order + 1，代表節(jié)點(diǎn)已使用，并遍歷當(dāng)前節(jié)點(diǎn)的所有祖先節(jié)點(diǎn)，更新節(jié)點(diǎn)值為各自的左右子節(jié)點(diǎn)值的最小值;如果否，執(zhí)行步驟3

• 步驟3 判斷是否當(dāng)前節(jié)點(diǎn)值memoryMap[id] <= d，且depth_of_id < h

如果是，則空閑節(jié)點(diǎn)在當(dāng)前節(jié)點(diǎn)的子節(jié)點(diǎn)中，則先判斷左子節(jié)點(diǎn)memoryMap[2 * id] <=d(判斷左子節(jié)點(diǎn)是否可分配)，如果成立，則當(dāng)前節(jié)點(diǎn)更新為左子節(jié)點(diǎn)，否則更新為右子節(jié)點(diǎn)，然后重復(fù)步驟2

參考示例如下圖，申請(qǐng)分配了chunkSize/2的內(nèi)存

 note：圖中雖然index = 2的子節(jié)點(diǎn)memoryMap[id] = depth_of_id，但實(shí)際上節(jié)點(diǎn)內(nèi)存已分配，因?yàn)樗惴ㄊ菑纳贤麻_始遍歷，所以在實(shí)際處理中，節(jié)點(diǎn)分配內(nèi)存后僅更新祖先節(jié)點(diǎn)的值，并沒有更新子節(jié)點(diǎn)的值。

釋放內(nèi)存時(shí)，根據(jù)申請(qǐng)內(nèi)存返回的id，將 memoryMap[id]更新為depth_of_id，同時(shí)設(shè)置id節(jié)點(diǎn)的祖先節(jié)點(diǎn)值為各自左右節(jié)點(diǎn)的最小值

1.4 巨型對(duì)象內(nèi)存管理

對(duì)于申請(qǐng)分配大小超過chunkSize的巨型對(duì)象(huge)，Netty采用的是非池化管理策略，在每次請(qǐng)求分配內(nèi)存時(shí)單獨(dú)創(chuàng)建特殊的非池化PoolChunk對(duì)象進(jìn)行管理，內(nèi)部memoryMap為null，當(dāng)對(duì)象內(nèi)存釋放時(shí)整個(gè)Chunk內(nèi)存釋放，相應(yīng)內(nèi)存申請(qǐng)邏輯在PoolArena#allocateHuge()方法中，釋放邏輯在PoolArena#destroyChunk()方法中。

1.5 小對(duì)象內(nèi)存管理

當(dāng)請(qǐng)求對(duì)象的大小reqCapacity <= 496，歸一化計(jì)算后方式是向上取最近的16的倍數(shù)，例如15規(guī)整為15、40規(guī)整為48、490規(guī)整為496，規(guī)整后的大小(normalizedCapacity)小于pageSize的小對(duì)象可分為2類：微型對(duì)象(tiny)：規(guī)整后為16的整倍數(shù)，如16、32、48、...、496，一共31種規(guī)格小型對(duì)象(small)：規(guī)整后為2的冪的，有512、1024、2048、4096，一共4種規(guī)格。

這些小對(duì)象直接分配一個(gè)page會(huì)造成浪費(fèi)，在page中進(jìn)行平衡樹的標(biāo)記又額外消耗更多空間，因此Netty的實(shí)現(xiàn)是：先PoolChunk中申請(qǐng)空閑page，同一個(gè)page分為相同大小規(guī)格的小內(nèi)存進(jìn)行存儲(chǔ)。

這些page用PoolSubpage對(duì)象進(jìn)行封裝，PoolSubpage內(nèi)部有記錄內(nèi)存規(guī)格大小(elemSize)、可用內(nèi)存數(shù)量(numAvail)和各個(gè)小內(nèi)存的使用情況，通過long[]類型的bitmap相應(yīng)bit值0或1，來記錄內(nèi)存是否已使用。

note：應(yīng)該有讀者注意到，Netty申請(qǐng)池化內(nèi)存進(jìn)行歸一化處理后的值更大了，例如1025byte會(huì)歸一化為2048byte，8193byte歸一化為16384byte，這樣是不是造成了一些浪費(fèi)?可以理解為是一種取舍，通過歸一化處理，使池化內(nèi)存分配大小規(guī)格化，大大方便內(nèi)存申請(qǐng)和內(nèi)存、內(nèi)存復(fù)用，提高效率。

2 彈性伸縮

前面的算法原理部分介紹了Netty如何實(shí)現(xiàn)內(nèi)存塊的申請(qǐng)和釋放，單個(gè)chunk比較容量有限，如何管理多個(gè)chunk，構(gòu)建成能夠彈性伸縮內(nèi)存池?

2.1 PoolChunk管理

為了解決單個(gè)PoolChunk容量有限的問題，Netty將多個(gè)PoolChunk組成鏈表一起管理，然后用PoolChunkList對(duì)象持有鏈表的head

將所有PoolChunk組成一個(gè)鏈表的話，進(jìn)行遍歷查找管理效率較低，因此Netty設(shè)計(jì)了PoolArena對(duì)象(arena中文是舞臺(tái)、場(chǎng)所)，實(shí)現(xiàn)對(duì)多個(gè)PoolChunkList、PoolSubpage的管理，線程安全控制、對(duì)外提供內(nèi)存分配、釋放的服務(wù)。

PoolArena內(nèi)部持有6個(gè)PoolChunkList，各個(gè)PoolChunkList持有的PoolChunk的使用率區(qū)間不同：

// 容納使用率 (0,25%) 的PoolChunkprivate 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個(gè)PoolChunkList對(duì)象組成雙向鏈表，當(dāng)PoolChunk內(nèi)存分配、釋放，導(dǎo)致使用率變化，需要判斷PoolChunk是否超過所在PoolChunkList的限定使用率范圍，如果超出了，需要沿著6個(gè)PoolChunkList的雙向鏈表找到新的合適PoolChunkList，成為新的head;同樣的，當(dāng)新建PoolChunk并分配完內(nèi)存，該P(yáng)oolChunk也需要按照上面邏輯放入合適的PoolChunkList中。

分配歸一化內(nèi)存normCapacity(大小范圍在[pageSize, chunkSize]) 具體處理如下：

• 按順序依次訪問q050、q025、q000、qInit、q075，遍歷PoolChunkList內(nèi)PoolChunk鏈表判斷是否有PoolChunk能分配內(nèi)存
• 如果上面5個(gè)PoolChunkList有任意一個(gè)PoolChunk內(nèi)存分配成功，PoolChunk使用率發(fā)生變更，重新檢查并放入合適的PoolChunkList中，結(jié)束
• 否則新建一個(gè)PoolChunk，分配內(nèi)存，放入合適的PoolChunkList中(PoolChunkList擴(kuò)容)

note：可以看到分配內(nèi)存依次優(yōu)先在q050 -> q025 -> q000 -> qInit -> q075的PoolChunkList的內(nèi)分配，這樣做的好處是，使分配后各個(gè)區(qū)間內(nèi)存使用率更多處于[75,100)的區(qū)間范圍內(nèi)，提高PoolChunk內(nèi)存使用率的同時(shí)也兼顧效率，減少在PoolChunkList中PoolChunk的遍歷。

當(dāng)PoolChunk內(nèi)存釋放，同樣PoolChunk使用率發(fā)生變更，重新檢查并放入合適的PoolChunkList中，如果釋放后PoolChunk內(nèi)存使用率為0，則從PoolChunkList中移除，釋放掉這部分空間，避免在高峰的時(shí)候申請(qǐng)過內(nèi)存一直緩存在池中(PoolChunkList縮容)。

 PoolChunkList的額定使用率區(qū)間存在交叉，這樣設(shè)計(jì)是因?yàn)槿绻谝粋€(gè)臨界值的話，當(dāng)PoolChunk內(nèi)存申請(qǐng)釋放后的內(nèi)存使用率在臨界值上下徘徊的話，會(huì)導(dǎo)致在PoolChunkList鏈表前后來回移動(dòng)

2.2 PoolSubpage管理

PoolArena內(nèi)部持有2個(gè)PoolSubpage數(shù)組，分別存儲(chǔ)tiny和small規(guī)格類型的PoolSubpage：

// 數(shù)組長度32，實(shí)際使用域從index = 1開始，對(duì)應(yīng)31種tiny規(guī)格PoolSubpageprivate final PoolSubpage<T>[] tinySubpagePools;// 數(shù)組長度4，對(duì)應(yīng)4種small規(guī)格PoolSubpageprivate final PoolSubpage<T>[] smallSubpagePools; 

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

 當(dāng)需要分配小內(nèi)存對(duì)象到PoolSubpage中時(shí)，根據(jù)歸一化后的大小，計(jì)算出需要訪問的PoolSubpage鏈表在tinySubpagePools和smallSubpagePools數(shù)組的下標(biāo)，訪問鏈表中的PoolSubpage的申請(qǐng)內(nèi)存分配，如果訪問到的PoolSubpage鏈表節(jié)點(diǎn)數(shù)為0，則創(chuàng)建新的PoolSubpage分配內(nèi)存然后加入鏈表。

PoolSubpage鏈表存儲(chǔ)的PoolSubpage都是已分配部分內(nèi)存，當(dāng)內(nèi)存全部分配完或者內(nèi)存全部釋放完的PoolSubpage會(huì)移出鏈表，減少不必要的鏈表節(jié)點(diǎn);當(dāng)PoolSubpage內(nèi)存全部分配完后再釋放部分內(nèi)存，會(huì)重新將加入鏈表。

PoolArean內(nèi)存池彈性伸縮可用下圖總結(jié)：

 3 并發(fā)設(shè)計(jì)

內(nèi)存分配釋放不可避免地會(huì)遇到多線程并發(fā)場(chǎng)景，無論是PoolChunk的平衡樹標(biāo)記或者PoolSubpage的bitmap標(biāo)記都是多線程不安全，如何在線程安全的前提下盡量提升并發(fā)性能?

首先，為了減少線程間的競(jìng)爭，Netty會(huì)提前創(chuàng)建多個(gè)PoolArena(默認(rèn)生成數(shù)量 = 2 * CPU核心數(shù))，當(dāng)線程首次請(qǐng)求池化內(nèi)存分配，會(huì)找被最少線程持有的PoolArena，并保存線程局部變量PoolThreadCache中，實(shí)現(xiàn)線程與PoolArena的關(guān)聯(lián)綁定(PoolThreadLocalCache#initialValue()方法)。

note：Java自帶的ThreadLocal實(shí)現(xiàn)線程局部變量的原理是：基于Thread的ThreadLocalMap類型成員變量，該變量中map的key為ThreadLocal，value-為需要自定義的線程局部變量值。調(diào)用ThreadLocal#get()方法時(shí)，會(huì)通過Thread.currentThread()獲取當(dāng)前線程訪問Thread的ThreadLocalMap中的值。

Netty設(shè)計(jì)了ThreadLocal的更高性能替代類：FastThreadLocal，需要配套繼承Thread的類FastThreadLocalThread一起使用，基本原理是將原來Thead的基于ThreadLocalMap存儲(chǔ)局部變量，擴(kuò)展為能更快速訪問的數(shù)組進(jìn)行存儲(chǔ)(Object[] indexedVariables)，每個(gè)FastThreadLocal內(nèi)部維護(hù)了一個(gè)全局原子自增的int類型的數(shù)組index。

此外，Netty還設(shè)計(jì)了緩存機(jī)制提升并發(fā)性能：當(dāng)請(qǐng)求對(duì)象內(nèi)存釋放，PoolArena并沒有馬上釋放，而是先嘗試將該內(nèi)存關(guān)聯(lián)的PoolChunk和chunk中的偏移位置(handler變量)等信息存入PoolThreadLocalCache中的固定大小緩存隊(duì)列中(如果緩存隊(duì)列滿了則馬上釋放內(nèi)存);當(dāng)請(qǐng)求內(nèi)存分配，PoolArena會(huì)優(yōu)先訪問PoolThreadLocalCache的緩存隊(duì)列中是否有緩存內(nèi)存可用，如果有，則直接分配，提高分配效率。

總結(jié)

Netty池化內(nèi)存管理的設(shè)計(jì)借鑒了Facebook的jemalloc，同時(shí)也與Linux內(nèi)存分配算法Buddy算法和Slab算法也有相似之處，很多分布式系統(tǒng)、框架的設(shè)計(jì)都可以在操作系統(tǒng)的設(shè)計(jì)中找到原型，學(xué)習(xí)底層原理是很有價(jià)值的。

參考

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

《Netty入門與實(shí)戰(zhàn)：仿寫微信 IM 即時(shí)通訊系統(tǒng)》https://juejin.im/book/5b4bc28bf265da0f60130116?referrer=598ff735f265da3e1c0f9643