从线上偶发的宕机事件看Netty流量控制

业务背景

目前移动端的使用场景中会用到大量的消息推送，push消息可以帮助运营人员更高效地实现运营目标（比如给用户推送营销活动或者提醒APP新功能）。

对于推送系统来说需要具备以下两个特性：

• 消息秒级送到用户，无延时，支持每秒百万推送，单机百万长连接。
• 支持通知、文本、自定义消息透传等展现形式。正是由于以上原因，对于系统的开发和维护带来了挑战。下图是推送系统的简单描述（API->推送模块->手机）。

问题背景

推送系统中长连接集群在稳定性测试、压力测试阶运行一段时间后随机会出现一个进程挂掉的情况，概率较小（频率为一个月左右发生一次），这会影响部分客户端消息送到的时效。

推送系统中的长连接节点（Broker系统）是基于Netty开发，此节点维护了服务端和手机终端的长连接，线上问题出现后，添加Netty内存泄露监控参数进行问题排查，观察多天但并未排查出问题。

由于长连接节点是Netty开发，为便于读者理解，下面简单介绍一下Netty。

Netty介绍

Netty是一个高性能、异步事件驱动的NIO框架，基于Java NIO提供的API实现。它提供了对TCP、UDP和文件传输的支持，作为当前最流行的NIO框架，Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，HBase，Hadoop，Bees，Dubbo等开源组件也基于Netty的NIO框架构建。

问题分析

猜想

最初猜想是长连接数导致的，但经过排查日志、分析代码，发现并不是此原因造成。

长连接数：39万，如下图：

连接数

每个channel字节大小1456, 按40万长连接计算，不致于产生内存过大现象。

查看GC日志

查看GC日志，发现进程挂掉之前频繁full GC（频率5分钟一次），但内存并未降低，怀疑堆外内存泄露。

分析heap内存情况

ChannelOutboundBuffer对象占将近5G内存，泄露原因基本可以确定：ChannelOutboundBuffer的entry数过多导致，查看ChannelOutboundBuffer的源码可以分析出，是ChannelOutboundBuffer中的数据。

没有写出去，导致一直积压；

ChannelOutboundBuffer内部是一个链表结构。