『神坑』DotNetty 内存泄漏 解决办法

『神坑』DotNetty 内存泄漏 解决办法,第1张

『神坑』DotNetty 内存泄漏 解决办法 背景

近来在用 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

知道了 内存泄漏 的数据 存在哪里,剩下的就是 删除这些数据。


因为 AllocatordirectArenas 都是不可访问的(私有类型)

我猜:按照微软框架的习惯,肯定有 属性 或 方法 能够设置 这个东西。


—— 是我想太多,我找了好久 都找不到 相关方法。


万能解法:反编译

直到数据在哪里,肯定有修正这些数据的方法。


反射是万能的 —— 但是我不想用。


于是,开始反编译:查看这个 directArenas 字段在哪里 赋值、哪里添加数据。


问题解决

再次运行程序,内存稳定在 30M —— 内存泄漏问题解决。


这次修改BUG,最废时间的 莫过于 DotNetty 毫无微软风格。


微软框架基本都有一个风格:底层一定提供了各种 函数、属性 —— 默认会给你一个 最稳定的默认值。


尼玛,这分明是 Java 的尿性:各种参数千奇百怪,不配参数还不能运行 —— 给我个默认参数 有那么难么~

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/586346.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-12
下一篇 2022-04-12

发表评论

登录后才能评论

评论列表(0条)

保存