背景
近来在用 DotNetty 实现一个文件上传下载的同步服务。
其中：客户端下载服务端的文件，客户端多次请求，从服务端将文件分片下载下来，追加到本地磁盘。
—— 非常简单的代码，都写了几十次了，驾轻就熟。
问题来了
可是：在进行压力测试时，我这边下载一个 Win10 的 ISO 镜像，4个G。
我发现：客户端内存不停增长，直到内存溢出 —— 我擦。
VS2015内存诊断
内存诊断，我们发现 有很多 16M(16777228字节) 的 byte[] 占据着内存。
而我请求服务端的 文件分片 只有 64K
—— 于是我肯定：这些 16M 的 byte[] 肯定是 DotNetty 创建的。
调试代码
通过调试代码，确实发现了 这些 16M 字节所在的位置：
((DotNetty.Buffers.PooledByteBufferAllocator)
((DotNetty.Transport.Channels.AbstractChannelHandlerContext)context)
.Allocator)
.directArenas
简写就是：
context.Allocator.directArenas
知道了 内存泄漏 的数据 存在哪里，剩下的就是 删除这些数据。
因为
Allocator和directArenas都是不可访问的（私有类型）我猜：按照微软框架的习惯，肯定有 属性 或 方法 能够设置 这个东西。
—— 是我想太多，我找了好久 都找不到 相关方法。
万能解法：反编译
直到数据在哪里，肯定有修正这些数据的方法。
反射是万能的 —— 但是我不想用。
于是，开始反编译：查看这个 directArenas 字段在哪里 赋值、哪里添加数据。
问题解决
再次运行程序，内存稳定在 30M —— 内存泄漏问题解决。
这次修改BUG，最废时间的 莫过于 DotNetty 毫无微软风格。
微软框架基本都有一个风格：底层一定提供了各种 函数、属性 —— 默认会给你一个 最稳定的默认值。
尼玛，这分明是 Java 的尿性：各种参数千奇百怪，不配参数还不能运行 —— 给我个默认参数 有那么难么~