netty使用中的LEAK: ByteBuf.release() was not called before it‘s garbage-collected

1.问题描述

使用netty做底层的tcp数据收发的项目时候，当对象上升到一定的时候（我这里是每秒1400的tcp包）会偶尔出现：LEAK: ByteBuf.release() was not called before it’s garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.Recent access records:

2.问题分析

我们是在数量多了以后遇到了这个问题，而且并不是平凡的触发这个东西。

同样书数量级我们先发开jvm 的GC日志看看

在idea的jvm启动项里面配置

-XX:+PrintGCDetails -XX:+PrintGCDateStamps

开启jvm的gc日志

我们看看是否是因为GC是主要的诱因。

业务逻辑是定时任务发送请求然后，然后得到modbusTCP的响应，通过2进制的数据对设备信息进行解析。也就是说一个modbusTCP响应是在22~24位的16进制数。现在是测试1000台循行情况看是否能处理过来。

我们发现并不是每一次GC都出现ByteBuf这里的这个错误。

也就是说GC并不是触发这个错误的核心的问题。但是在错误的信息里面确实提到了垃圾回收。

所以我们可以做一个假设，按照错误的描述内容，byteBuff在执行release方法之前就被垃圾回收了，这个回收的byteBuff，也就是byteBuff意外关闭了。即这部分你的内存泄漏了。

3.问题解决

通过查找，jvm对于这部分的可以通过添加运行参数，在netty添加相关的处理器

ResourceLeakDetector.setLevel(ResourceLeakDetector.Level.ADVANCED);

加载netty配置的位置

  serverBootstrap
                .group(bossGroup, workerGroup)
                .channel(NioServerSocketChannel.class)
                // option()和handler()都是给bossGroup设置的；握手字符串长度
                .option(ChannelOption.SO_BACKLOG, 1024)
                .option(ChannelOption.TCP_NODELAY, true)
                .handler(new LoggingHandler(LogLevel.INFO))
                .childHandler(workReceivedChannelInitialize);
        Log.get().info("初始化完毕");
		//  加在这里
        ResourceLeakDetector.setLevel(ResourceLeakDetector.Level.ADVANCED);
        channelFuture = serverBootstrap.bind(inetSocketAddress).sync();

打印的日志出现了位置信息

4.解决

既然知道了内存泄漏的位置，只要在使用完手动释放即可

对于byteBuff只要调用其release方法就可以了

info.readBytes(message);
String data = ByteArrayToString.byteArrayToHexString(message);
        // 读完就释放
info.release();

本文地址：https://blog.csdn.net/weixin_45568648/article/details/112023960