在本系列的上一篇《Netty 内存管理探险: PoolArena 分配之谜》中，我们将 xharbor 的启动参数扩充为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 参数确保至少存在一个DirectMemory内存池; -Dio.netty.allocator.type=pooled参数指定缺省的内存管理策略为池化(pooled)方式; 后面三个启动参数禁用了 Netty 池化内存的线程局部缓存，方便我们检查是否有内存使用上的泄漏(ByteBuf LEAK)。启动 xharbor，在线上运行一段时间后，通过 xbeacon 观察到内存池 PoolArena 上的分配/释放/活跃 指标如下图所示：
虽然分配和释放的总数相等，都是 2404，但 tiny / small / normal 分项统计存在令人费解的误差。tiny / small 类型的释放数比分配数要多，而 normal 的释放数始终比分配数要少。
备注：关于 PoolArena 的四种内存分配尺寸，请参见 Netty内存池原理分析，此处不再赘述原理。
这造型很像是有BUG啊？！还是从代码去探索真相吧！
PoolArena 统计指标确有BUG
跟着 PoolArena 的分配内存入口函数 allocate 跟踪下去，唯一增加 tiny / small 分配计数的代码片段如下：
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 是成立的。相关代码片段位于 PoolArena 的构造函数中：
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 的内存页面，代码如下：
private PoolSubpage<T> newSubpagePoolHead(int pageSize) {
PoolSubpage<T> head = new PoolSubpage<T>(pageSize);
head.prev = head;
head.next = head;
return head;
}
各位观众，看到了吧！在上面的代码中，初始化完成后的 tiny / small 内存页面 head.next == head。因此，不同尺寸的 tiny / small 的首次分配没有使对应的计数器加1，而是直接调用 allocateNormal 来完成内存分配。
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 中分配到内存，还是在最后，创建一个新的 memory chunk(还记得缺省情况下，一个chunk的尺寸吗？是16M哦)，直接在 chunk 中分配内存，都妥妥的是将 normal 类型的计数器做了加1。因此，真相大白了：在 netty 4.0.43 (4.0.x 分支) 和 4.1.7 (4.1.x 分支) 及以前的版本中，一部分的 tiny / small 分配行为错误地对 normal 类型的计数器增加了计数，才出现了本文开始截图中的统计指标分项误差。
若干细节的确认
接下来，我们通过确认若干细节来加强这一BUG的判断可信度。
- 通过 allocateNormal 能分配出适当的 tiny / small 内存大小吗？
在 allocateNormal 中，事实上是通过 PoolChunk.allocate 来分配内存的，代码如下：
long allocate(int normCapacity) {
if ((normCapacity & subpageOverflowMask) != 0) {
// >= pageSize
return allocateRun(normCapacity);
} else {
return allocateSubpage(normCapacity);
}
}
如上所示，最终还是根据normCapacity的大小来分别调用 allocateSubpage(单页面内分配 tiny / small 类型内存)和allocateRun(连续的多页分配 normal 类型内存) 分配内存块的。
- Deallocation 的分项计数为什么是正确的？
内存块的释放(Deallocation)计数是在 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);
}
}
可以看到，释放计数是根据SizeClass来确定的，因此不存在类似分配计数的问题。
发现BUG后的动作...
发现BUG后，接下来怎么做？在开源世界里，很简单：在源库中提交 issue，更进一步，还可以提交一个 Pull Request 向代码库维护成员提供BUG的解决方案。我也正是这么做的。我向 netty 提交的 issue 编号为 #6282: Incorrect allocations value for PoolArena (tiny / small / normal)。如果读者打开链接，可以看到，我基本上把本文内容在 issue 描述中复述了一遍。一开始，netty 的主要贡献者 normanmaurer 也误以为是没有考虑线程局部缓存的原因，他的回复如下：
我赶紧又 balabalabala...... 说明已经禁用了 ThreadLocal cache(参见本系列第二篇《Netty 内存管理探险: PoolArena 分配之谜》中对线程局部缓存的说明)，但分项计数还是有误差哦。normanmaurer 仔细一瞅，晕！此处确有问题。接下来几天来回探讨了我提交的 Pull Request 中的风格、性能等问题，不得不说，netty 库的作者们确实在性能上颇为重视。
如下是我的初始提交版本和 normanmaurer 的修正版本：
- 我的初始提交版本
https://github.com/netty/netty/pull/6288/commits/e0b79fe7e7e70ccaf5c3178be773c0a8a552a1fe - normanmaurer的修正版本：
https://github.com/netty/netty/commit/f10f8a31318a2e408b979de6a8ed49caa615d86a
感兴趣的读者可打开链接感受下大神们对代码的极致追求。
所以最终的结果是：该 PR 被接受并放到写本系列时才发布的 netty 最新版本 4.0.44.Final/4.1.8.Final 中。
用 4.1.8.Final 验证一下
将 xharbor 依赖的 netty 版本升级到 4.1.8.Final，编译/打包/上线/运行验证结果如下图所示：
从图上看，总分配和总释放数量，以及各个分项指标对应的内存分配计数和释放计数数值完全相等。至此，对于 Netty池化内存管理的统计指标，我们总算有了一个精确的工具。
总结
对于使用池化内存管理策略的 Netty 应用，如果要精确查看内存使用是否存在泄漏，请按照如下步骤配置：
- 确保使用 netty 4.0.44.Final 、4.1.8.Final 或其后续版本；
- 在 JVM 启动参数中添加如下5个：
-XX:MaxDirectMemorySize=96M
-Dio.netty.allocator.type=pooled
-Dio.netty.allocator.tinyCacheSize=0
-Dio.netty.allocator.smallCacheSize=0
-Dio.netty.allocator.normalCacheSize=0
- 编程导出应用所使用的 PooledByteBufAllocator.directArenas 各个属性，也可直接使用 jocean-http 库中的统计POJO 类：PooledAllocatorStats
在此，笔者祝大家在使用 netty 的道路上知己知彼，放心的享用这一高性能的异步IO框架大餐。
下一篇，我想聊聊这个系列文章的源起：我们自研的微服务框架核心部件之一—— API 网关服务 xharbor 。
本系列：
参考：
