长连接Netty服务内存泄漏，看我如何一步步捉“虫”解决

京东技术

发布于 2023-08-22 15:25:47

6861

发布于 2023-08-22 15:25:47

Tech 导读本文介绍了长连接服务中使用Netty框架，对内存泄漏问题的排查、复现、解决的案例，是研发开发中非常典型的实战问题解决。同时本文介绍了Netty中对象的引用计数机制，并总结了Netty内存泄漏问题的排查方案。（本文作者以第一人称视角写作）

背景

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

事情要回顾到11.11备战前夕，在那个风雨交加的夜晚，一个急促的内网消息报警，惊破了电闪雷鸣的黑夜，将沉浸在梦乡，熟睡的我惊醒。

一看手机的消息通知，不好！有大事发生了！电话马上打给老板：

老板说：长连接吗? 我说：是的！老板说：该来的还是要来的，最终还是来了，快，赶紧先把服务重启下！我说：已经重启了！老板说：这问题必须给我解决了！我说：必须的！

线上应用长连接Netty服务出现内存泄漏了！真让人头大。

在这风雨交加的夜晚，此时，面对毫无头绪的问题，以及迫切想攻克问题的心，已经让我兴奋不已，一把揉揉刚还迷糊的眼，今晚又注定是一个不眠之夜！

应用介绍

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

说起支付业务的长连接服务，真是说来话长，我们这就长话短说：

随着业务及系统架构的复杂化，一些场景，用户操作无法同步得到结果。一般采用的短连接轮训的策略，客户端需要不停的发起请求，时效性较差还浪费服务器资源。

短轮训痛点:

时效性差
耗费服务器性能
建立、关闭链接频繁

相比于短连接轮训策略，长连接服务可做到实时推送数据，并且在一个链接保持期间可进行多次数据推送。服务应用常见场景：PC端扫码支付，用户打开扫码支付页面，手机扫码完成支付，页面实时展示支付成功信息，提供良好的用户体验。

长连服务优势:

时效性高提升用户体验
减少链接建立次数
一次链接多次推送数据
提高系统吞吐量

图1.使用Netty框架的长连接服务

这个长连接服务使用Netty框架，Netty的高性能为这个应用带来了无上的荣光，承接了众多长连接使用场景的业务：

PC收银台微信支付
声波红包
POS线下扫码支付

问题现象

回到线上问题，出现内存泄漏的是长连接前置服务，观察线上服务，这个应用的内存泄漏的现象总伴随着内存的增长，这个增长真是非常的缓慢，缓慢，缓慢，2、3个月内从30%慢慢增长到70%，极难发现：

图2.内存泄漏的现象总伴随着内存的缓慢增长

每次发生内存泄漏，内存快耗尽时，总得重启下，虽说重启是最快解决的方法，但是程序员是天生懒惰的，要数着日子来重启，那绝对不是一个优秀程序员的行为！问题必须彻底解决！

问题排查与复现

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目

4.1 排查

遇到问题，毫无头绪，首先还是需要去案发第一现场，排查“死者(应用实例)”死亡现场，通过在发生FullGC的时间点，通过Digger查询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的日志提示还是非常完善：启用高级泄漏报告找出泄漏发生位置嘛，生产上不可能启用，并且生产发生时间极长，时间上来不及，而且未经验证，不能直接生产发布，那就本地代码复现一下！找到具体代码位置。

为了本地复现Netty泄漏，定位详细的内存泄漏代码，我们需要做这几步：

1、配置足够小的本地JVM内存，以便快速模拟堆外内存泄漏。

如图，我们设置PermSize=30M, MaxPermSize=43M

图4.配置足够小的本地JVM内存

2、模拟足够多的长连接请求，我们使用Postman定时批量发请求，以达到服务的堆外内存泄漏。

启动项目，通过JProfiler JVM监控工具，我们观察到内存缓慢的增长，最终触发了本地Netty的堆外内存泄漏，本地复现成功：

图5.本地复现

那问题具体出现在代码中哪块呢？ 我们最重要的是定位具体代码，在开启了Netty的高级内存泄漏级别为高级，来定位下：

图6.定位具体代码

3、开启Netty的高级内存泄漏检测级别，JVM参数如下：

-Dio.netty.leakDetectionLevel=advanced

图7.开启Netty的高级内存泄漏检测级别

再启动项目，模拟请求，达到本地应用JVM内存泄漏，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 COMPLETE
2020-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)