近来在用 DotNetty 实现一个文件上传下载的同步服务。
其中:客户端下载服务端的文件,客户端多次请求,从服务端将文件分片下载下来,追加到本地磁盘。
—— 非常简单的代码,都写了几十次了,驾轻就熟。
可是:在进行压力测试时,我这边下载一个 Win10 的 ISO 镜像,4个G。
我发现:客户端内存不停增长,直到内存溢出 —— 我擦。
内存诊断,我们发现 有很多 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 的尿性:各种参数千奇百怪,不配参数还不能运行 —— 给我个默认参数 有那么难么~
原文:https://www.cnblogs.com/shuxiaolong/p/DotNetty_OutOfMemory.html