在本系列的上一篇《Netty 內(nèi)存管理探險: PoolArena 分配之謎》中，我們將 xharbor 的啟動參數(shù)擴充為5個：
-XX:MaxDirectMemorySize=96M
-Dio.netty.allocator.type=pooled
-Dio.netty.allocator.tinyCacheSize=0
-Dio.netty.allocator.smallCacheSize=0
-Dio.netty.allocator.normalCacheSize=0
-XX:MaxDirectMemorySize=96M 參數(shù)確保至少存在一個DirectMemory內(nèi)存池; -Dio.netty.allocator.type=pooled參數(shù)指定缺省的內(nèi)存管理策略為池化(pooled)方式; 后面三個啟動參數(shù)禁用了 Netty 池化內(nèi)存的線程局部緩存，方便我們檢查是否有內(nèi)存使用上的泄漏(ByteBuf LEAK)。啟動 xharbor，在線上運行一段時間后，通過 xbeacon 觀察到內(nèi)存池 PoolArena 上的分配/釋放/活躍 指標如下圖所示：
雖然分配和釋放的總數(shù)相等，都是 2404，但 tiny / small / normal 分項統(tǒng)計存在令人費解的誤差。tiny / small 類型的釋放數(shù)比分配數(shù)要多，而 normal 的釋放數(shù)始終比分配數(shù)要少。
備注：關(guān)于 PoolArena 的四種內(nèi)存分配尺寸，請參見 Netty內(nèi)存池原理分析，此處不再贅述原理。
這造型很像是有BUG啊？！還是從代碼去探索真相吧！
PoolArena 統(tǒng)計指標確有BUG
跟著 PoolArena 的分配內(nèi)存入口函數(shù) allocate 跟蹤下去，唯一增加 tiny / small 分配計數(shù)的代碼片段如下：
synchronized (head) {
final PoolSubpage<T> s = head.next;
if (s != head) {
assert s.doNotDestroy && s.elemSize == normCapacity;
long handle = s.allocate();
assert handle >= 0;
s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
if (tiny) {
allocationsTiny.increment();
} else {
allocationsSmall.increment();
}
return;
}
}
allocateNormal(buf, reqCapacity, normCapacity);
return;
但是... 但是...各位觀眾....問題來了，當上面代碼中的雙向鏈表初始化的時候, s == head 是成立的。相關(guān)代碼片段位于 PoolArena 的構(gòu)造函數(shù)中：
tinySubpagePools = newSubpagePoolArray(numTinySubpagePools);
for (int i = 0; i < tinySubpagePools.length; i ++) {
tinySubpagePools[i] = newSubpagePoolHead(pageSize);
}
...
smallSubpagePools = newSubpagePoolArray(numSmallSubpagePools);
for (int i = 0; i < smallSubpagePools.length; i ++) {
smallSubpagePools[i] = newSubpagePoolHead(pageSize);
}
而 newSubpagePoolHead 的功能是初始化 tiny / small 的內(nèi)存頁面，代碼如下：
private PoolSubpage<T> newSubpagePoolHead(int pageSize) {
PoolSubpage<T> head = new PoolSubpage<T>(pageSize);
head.prev = head;
head.next = head;
return head;
}
各位觀眾，看到了吧！在上面的代碼中，初始化完成后的 tiny / small 內(nèi)存頁面 head.next == head。因此，不同尺寸的 tiny / small 的首次分配沒有使對應(yīng)的計數(shù)器加1，而是直接調(diào)用 allocateNormal 來完成內(nèi)存分配。
private synchronized void allocateNormal(
PooledByteBuf<T> buf,
int reqCapacity,
int normCapacity) {
if (q050.allocate(buf, reqCapacity, normCapacity)
|| q025.allocate(buf, reqCapacity, normCapacity)
|| q000.allocate(buf, reqCapacity, normCapacity)
|| qInit.allocate(buf, reqCapacity, normCapacity)
|| q075.allocate(buf, reqCapacity, normCapacity)) {
++allocationsNormal;
return;
}
// Add a new chunk.
PoolChunk<T> c = newChunk(
pageSize, maxOrder, pageShifts, chunkSize);
long handle = c.allocate(normCapacity);
++allocationsNormal;
assert handle > 0;
c.initBuf(buf, handle, reqCapacity);
qInit.add(c);
}
如上所示，在 allocateNormal 中，無論是從 q050/q025/q000/qInit/q075 中分配到內(nèi)存，還是在最后，創(chuàng)建一個新的 memory chunk(還記得缺省情況下，一個chunk的尺寸嗎？是16M哦)，直接在 chunk 中分配內(nèi)存，都妥妥的是將 normal 類型的計數(shù)器做了加1。因此，真相大白了：在 netty 4.0.43 (4.0.x 分支) 和 4.1.7 (4.1.x 分支) 及以前的版本中，一部分的 tiny / small 分配行為錯誤地對 normal 類型的計數(shù)器增加了計數(shù)，才出現(xiàn)了本文開始截圖中的統(tǒng)計指標分項誤差。
若干細節(jié)的確認
接下來，我們通過確認若干細節(jié)來加強這一BUG的判斷可信度。
- 通過 allocateNormal 能分配出適當?shù)?tiny / small 內(nèi)存大小嗎？
在 allocateNormal 中，事實上是通過 PoolChunk.allocate 來分配內(nèi)存的，代碼如下：
long allocate(int normCapacity) {
if ((normCapacity & subpageOverflowMask) != 0) {
// >= pageSize
return allocateRun(normCapacity);
} else {
return allocateSubpage(normCapacity);
}
}
如上所示，最終還是根據(jù)normCapacity的大小來分別調(diào)用 allocateSubpage(單頁面內(nèi)分配 tiny / small 類型內(nèi)存)和allocateRun(連續(xù)的多頁分配 normal 類型內(nèi)存) 分配內(nèi)存塊的。
- Deallocation 的分項計數(shù)為什么是正確的？
內(nèi)存塊的釋放(Deallocation)計數(shù)是在 freeChunk 中進行的，代碼如下：
void freeChunk(PoolChunk<T> chunk, long handle,
SizeClass sizeClass) {
final boolean destroyChunk;
synchronized (this) {
switch (sizeClass) {
case Normal:
++deallocationsNormal;
break;
case Small:
++deallocationsSmall;
break;
case Tiny:
++deallocationsTiny;
break;
default:
throw new Error();
}
destroyChunk = !chunk.parent.free(chunk, handle);
}
if (destroyChunk) {
// destroyChunk not need to be called
// while holding the synchronized lock.
destroyChunk(chunk);
}
}
可以看到，釋放計數(shù)是根據(jù)SizeClass來確定的，因此不存在類似分配計數(shù)的問題。
發(fā)現(xiàn)BUG后的動作...
發(fā)現(xiàn)BUG后，接下來怎么做？在開源世界里，很簡單：在源庫中提交 issue，更進一步，還可以提交一個 Pull Request 向代碼庫維護成員提供BUG的解決方案。我也正是這么做的。我向 netty 提交的 issue 編號為 #6282: Incorrect allocations value for PoolArena (tiny / small / normal)。如果讀者打開鏈接，可以看到，我基本上把本文內(nèi)容在 issue 描述中復(fù)述了一遍。一開始，netty 的主要貢獻者 normanmaurer 也誤以為是沒有考慮線程局部緩存的原因，他的回復(fù)如下：
我趕緊又 balabalabala...... 說明已經(jīng)禁用了 ThreadLocal cache(參見本系列第二篇《Netty 內(nèi)存管理探險: PoolArena 分配之謎》中對線程局部緩存的說明)，但分項計數(shù)還是有誤差哦。normanmaurer 仔細一瞅，暈！此處確有問題。接下來幾天來回探討了我提交的 Pull Request 中的風格、性能等問題，不得不說，netty 庫的作者們確實在性能上頗為重視。
如下是我的初始提交版本和 normanmaurer 的修正版本：
- 我的初始提交版本
https://github.com/netty/netty/pull/6288/commits/e0b79fe7e7e70ccaf5c3178be773c0a8a552a1fe - normanmaurer的修正版本：
https://github.com/netty/netty/commit/f10f8a31318a2e408b979de6a8ed49caa615d86a
感興趣的讀者可打開鏈接感受下大神們對代碼的極致追求。
所以最終的結(jié)果是：該 PR 被接受并放到寫本系列時才發(fā)布的 netty 最新版本 4.0.44.Final/4.1.8.Final 中。
用 4.1.8.Final 驗證一下
將 xharbor 依賴的 netty 版本升級到 4.1.8.Final，編譯/打包/上線/運行驗證結(jié)果如下圖所示：
從圖上看，總分配和總釋放數(shù)量，以及各個分項指標對應(yīng)的內(nèi)存分配計數(shù)和釋放計數(shù)數(shù)值完全相等。至此，對于 Netty池化內(nèi)存管理的統(tǒng)計指標，我們總算有了一個精確的工具。
總結(jié)
對于使用池化內(nèi)存管理策略的 Netty 應(yīng)用，如果要精確查看內(nèi)存使用是否存在泄漏，請按照如下步驟配置：
- 確保使用 netty 4.0.44.Final 、4.1.8.Final 或其后續(xù)版本；
- 在 JVM 啟動參數(shù)中添加如下5個：
-XX:MaxDirectMemorySize=96M
-Dio.netty.allocator.type=pooled
-Dio.netty.allocator.tinyCacheSize=0
-Dio.netty.allocator.smallCacheSize=0
-Dio.netty.allocator.normalCacheSize=0
- 編程導(dǎo)出應(yīng)用所使用的 PooledByteBufAllocator.directArenas 各個屬性，也可直接使用 jocean-http 庫中的統(tǒng)計POJO 類：PooledAllocatorStats
在此，筆者祝大家在使用 netty 的道路上知己知彼，放心的享用這一高性能的異步IO框架大餐。
下一篇，我想聊聊這個系列文章的源起：我們自研的微服務(wù)框架核心部件之一—— API 網(wǎng)關(guān)服務(wù) xharbor 。
本系列：
參考：
