长连接Netty服务内存泄漏，看我如何一步步捉“虫”解决
![]()
Tech 导读
本文介绍了长连接服务中使用Netty框架，对内存泄漏问题的排查、复现、解决的案例，是研发开发中非常典型的实战问题解决。同时本文介绍了Netty中对象的引用计数机制，并总结了Netty内存泄漏问题的排查方案。 （本文作者以第一人称视角写作）
导读
事情要回顾到11.11备战前夕，在那个风雨交加的夜晚，一个急促的内网消息报警，惊破了电闪雷鸣的黑夜，将沉浸在梦乡，熟睡的我惊醒。
一看手机的消息通知，不好！有大事发生了！电话马上打给老板：
老板说：长连接吗?
我说：是的！
老板说：该来的还是要来的，最终还是来了，快，赶紧先把服务重启下！
我说：已经重启了！
老板说：这问题必须给我解决了！
我说：必须的！
线上应用长连接Netty服务出现内存泄漏了！真让人头大。
应用介绍
短轮训痛点:
时效性差 耗费服务器性能 建立、关闭链接频繁
相比于短连接轮训策略，长连接服务可做到实时推送数据，并且在一个链接保持期间可进行多次数据推送。服务应用常见场景：PC端扫码支付，用户打开扫码支付页面，手机扫码完成支付，页面实时展示支付成功信息，提供良好的用户体验。
长连服务优势:
时效性高提升用户体验 减少链接建立次数 一次链接多次推送数据 提高系统吞吐量
Netty框架的长连接服务这个长连接服务使用Netty框架，Netty的高性能为这个应用带来了无上的荣光，承接了众多长连接使用场景的业务：
PC收银台微信支付
声波红包
POS线下扫码支付
问题现象
图2.内存泄漏的现象总伴随着内存的缓慢增长
每次发生内存泄漏，内存快耗尽时，总得重启下，虽说重启是最快解决的方法，但是程序员是天生懒惰的，要数着日子来重启，那绝对不是一个优秀程序员的行为！问题必须彻底解决！
4.1 排查
ERROR日志，没想到还真找到破案的第一线索:图3.通过Digger查询
ERROR日志得到线索
io.netty.util.ResourceLeakDetector [176] - LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetection.level=advanced' or call ResourceLeakDetector.setLevel() See http://netty.io/wiki/reference-counted-objects.html for more information."LEAK"泄漏字样，作为技术人的敏锐的技术嗅觉，和找Bug的直觉，可以确认，这就是事故案发第一现场。ByteBuf.release（） 在垃圾回收之前没有被调用。启用高级泄漏报告以找出泄漏发生的位置。要启用高级泄漏报告，请指定 JVM 选项“-Dio.netty.leakDetectionLevel=advanced”或调用 ResourceLeakDetector.setLevel（）
啊哈！这信息不就是说了嘛！ByteBuf.release()在垃圾回收前没有调用，有ByteBuf对象没有被释放，ByteBuf可是分配在直接内存的，没有被释放，那就意味着堆外内存泄漏，所以内存一直是非常缓慢的增长，GC都不能够进行释放。
提供了这个线索，那到底是我们应用中哪段代码出现了ByteBuf对象的内存泄漏呢？
项目这么大，Netty通信处理那么多，怎么找呢？自己从中搜索，那肯定是不靠谱，找到了又怎么释放呢？
4.2 复现
Netty泄漏，定位详细的内存泄漏代码，我们需要做这几步：1、配置足够小的本地JVM内存，以便快速模拟堆外内存泄漏。
图4.配置足够小的本地JVM内存
2、模拟足够多的长连接请求，我们使用Postman定时批量发请求，以达到服务的堆外内存泄漏。
启动项目，通过JProfiler JVM监控工具，我们观察到内存缓慢的增长，最终触发了本地Netty的堆外内存泄漏，本地复现成功：
图5.本地复现
那问题具体出现在代码中哪块呢？ 我们最重要的是定位具体代码，在开启了Netty的高级内存泄漏级别为高级，来定位下：
3、开启Netty的高级内存泄漏检测级别，JVM参数如下：
-Dio.netty.leakDetectionLevel=advanced
图7.开启
Netty的高级内存泄漏检测级别
2020-09-24 20:11:59.078 [nioEventLoopGroup-3-1] INFO io.netty.handler.logging.LoggingHandler [101] - [id: 0x2a5e5026, L:/0:0:0:0:0:0:0:0:8883] READ: [id: 0x926e140c, L:/127.0.0.1:8883 - R:/127.0.0.1:58920]2020-09-24 20:11:59.078 [nioEventLoopGroup-3-1] INFO io.netty.handler.logging.LoggingHandler [101] - [id: 0x2a5e5026, L:/0:0:0:0:0:0:0:0:8883] READ COMPLETE2020-09-24 20:11:59.079 [nioEventLoopGroup-2-8] ERROR io.netty.util.ResourceLeakDetector [171] - LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.WARNING: 1 leak records were discarded because the leak record count is limited to 4. Use system property io.netty.leakDetection.maxRecords to increase the limit.Recent access records: 5#5:io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.readBytes(AdvancedLeakAwareCompositeByteBuf.java:476)io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.readBytes(AdvancedLeakAwareCompositeByteBuf.java:36)com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.getClientMassageInfo(LongRotationServerHandler.java:169)com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.handleHttpFrame(LongRotationServerHandler.java:121)com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.channelRead(LongRotationServerHandler.java:80)io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)......#4:Hint: 'LongRotationServerHandler#0' will handle the message from this point.io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)......#3:Hint: 'HttpServerExpectContinueHandler#0' will handle the message from this point.io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)......#2:Hint: 'HttpHeartbeatHandler#0' will handle the message from this point.io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)......#1:Hint: 'IdleStateHandler#0' will handle the message from this point.io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)......Created at:io.netty.util.ResourceLeakDetector.track(ResourceLeakDetector.java:237)io.netty.buffer.AbstractByteBufAllocator.compositeDirectBuffer(AbstractByteBufAllocator.java:217)io.netty.buffer.AbstractByteBufAllocator.compositeBuffer(AbstractByteBufAllocator.java:195)io.netty.handler.codec.MessageAggregator.decode(MessageAggregator.java:255)......
开启高级的泄漏检测级别后，通过上面异常日志，我们可以看到内存泄漏的具体地方：com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.getClientMassageInfo(LongRotationServerHandler.java:169)
不得不说Netty 内存泄漏排查这点是真香！真香好评！
找到问题了，那我们就需要解决，如何释放ByteBuf内存呢？
5.1 如何回收泄漏的ByteBuf
其实Netty官方也针对这个问题做了专门的讨论，一般的经验法则是，最后访问引用计数对象的一方负责销毁该引用计数对象，具体来说：
如果一个[发送]组件将一个引用计数的对象传递给另一个[接收]组件，则发送组件通常不需要销毁它，而是由接收组件进行销毁。
如果一个组件使用了一个引用计数的对象，并且知道没有其他对象将再访问它（即，不会将引用传递给另一个组件），则该组件应该销毁它。
详情请看翻译的Netty官方文档对引用计数的功能使用：
【翻译】Netty的对象引用计数：https://developer.jdcloud.com/article/2900?mid=30
【原文】Reference counted objects：https://netty.io/wiki/reference-counted-objects.html
总结起来主要三个方式：
方式一：
手动释放，哪里使用了，使用完就手动释放。
如果处理过程中不确定ByteBuf是否应该被释放，那交给Netty的ReferenceCountUtil.release(msg)来释放，这个方法会判断上下文是否可以释放。
ChannelHandler，如果升级SimpleChannelHandler对现有API接口变动比较大，同时如果手动释放，不确定是否应该释放风险也大，因此使用方式三，如下：5.2 线上实例内存正常
FullHttpRequest中ByteBuf内存释放成功。 从此长连接前置内存泄漏的问题彻底解决。一、Netty的内存泄漏排查其实并不难，Netty提供了比较完整的排查内存泄漏工具
-Dio.netty.leakDetection.level
目前有 4 个泄漏检测级别的：
DISABLED - 完全禁用泄漏检测。不推荐。
SIMPLE - 抽样 1% 的缓冲区是否有泄漏。默认。
ADVANCED - 抽样 1% 的缓冲区是否泄漏，以及能定位到缓冲区泄漏的代码位置。
PARANOID - 与 ADVANCED 相同，只是它适用于每个缓冲区，适用于自动化测试阶段。如果生成输出包含“LEAK：”，则可能会使生成失败。
即：-Dio.netty.leakDetectionLevel=advanced定位到了具体内存泄漏的代码。
同时Netty也给出了避免泄漏的最佳实践：
在 PARANOID 泄漏检测级别以及 SIMPLE 级别运行单元测试和集成测试。
在 SIMPLE 级别向整个集群推出应用程序之前，请先在相当长的时间内查看是否存在泄漏。
如果有泄漏，灰度发布中使用 ADVANCED 级别，以获得有关泄漏来源的一些提示。
不要将泄漏的应用程序部署到整个群集。
二、解决Netty内存泄漏，Netty也提供了指导方案，主要有三种方式
求分享
求点赞
求在看