Netty 3 版本升级遭遇内存泄漏案例

Posted 2021-04-30 Netty之家

问题描述：业务代码升级Netty 3到Netty4之后，运行一段时间，Java进程就会宕机，查看系统运行日志发现系统发生了内存泄露（示例堆栈）：

---

---

对内存进行监控（切换使用堆内存池，方便对内存进行监控），发现堆内存一直飙升，如下所示（示例堆内存监控）：

---

---

问题定位

使用 jmap -dump:format=b,file=netty.bin PID 将堆内存dump出来，通过IBM的HeapAnalyzer工具进行分析，发现ByteBuf发生了泄露。

因为使用了Netty 4的内存池，所以首先怀疑是不是申请的ByteBuf没有被释放导致？查看代码，发现消息发送完成之后，Netty底层已经调用ReferenceCountUtil.release(message)对内存进行了释放。这是怎么回事呢？难道Netty 4.X的内存池有Bug，调用release操作释放内存失败？

考虑到Netty 内存池自身Bug的可能性不大，首先从业务的使用方式入手分析：

1、内存的分配是在业务代码中进行，由于使用到了业务线程池做I/O操作和业务操作的隔离，实际上内存是在业务线程中分配的；

2、内存的释放操作是在outbound中进行，按照Netty 3的线程模型，downstream（对应Netty 4的outbound，Netty 4取消了upstream和downstream）的handler也是由业务调用者线程执行的，也就是说申请和释放在同一个业务线程中进行。

初次排查并没有发现导致内存泄露的根因，继续分析Netty内存池的实现原理。

---

Netty 内存池实现原理分析

查看Netty的内存池分配器PooledByteBufAllocator的源码实现，发现内存池实际是基于线程上下文实现的，相关代码如下：

---

final ThreadLocal<PoolThreadCache> threadCache = new ThreadLocal<PoolThreadCache>() {

private final AtomicInteger index = new AtomicInteger();

@Override

protected PoolThreadCache initialValue() {

final int idx = index.getAndIncrement();

final PoolArena<byte[]> heapArena;

final PoolArena<ByteBuffer> directArena;

//......此处代码省略

return new PoolThreadCache(heapArena, directArena);

}

---

也就是说内存的申请和释放必须在同一线程上下文中，不能跨线程。跨线程之后实际操作的就不是同一块儿内存区域，这会导致很多严重的问题，内存泄露便是其中之一。内存在A线程申请，切换到B线程释放，实际是无法正确回收的。

---

问题根因

Netty 4修改了Netty 3的线程模型：在Netty 3的时候，upstream是在I/O线程里执行的，而downstream是在业务线程里执行。当Netty从网络读取一个数据报投递给业务handler的时候，handler是在I/O线程里执行；而当我们在业务线程中调用write和writeAndFlush向网络发送消息的时候,handler是在业务线程里执行，直到最后一个Header handler将消息写入到发送队列中，业务线程才返回。

Netty4修改了这一模型，在Netty 4里inbound(对应Netty 3的upstream)和outbound(对应Netty 3的downstream)都是在NioEventLoop(I/O线程)中执行。当我们在业务线程里通过ChannelHandlerContext.write发送消息的时候，Netty 4在将消息发送事件调度到ChannelPipeline的时候，首先将待发送的消息封装成一个Task，然后放到NioEventLoop的任务队列中，由NioEventLoop线程异步执行。后续所有handler的调度和执行，包括消息的发送、I/O事件的通知，都由NioEventLoop线程负责处理。

在本案例中，ByteBuf在业务线程中申请，在后续的ChannelHandler中释放，ChannelHandler是由Netty的I/O线程(EventLoop)执行的，因此内存的申请和释放不在同一个线程中，导致内存泄漏。

---

Netty 3和Netty 4线程模型对比

Netty 3的I/O事件处理流程：

---

---

Netty 4的I/O消息处理流程：

---

---

案例总结

Netty 4.X版本新增的内存池确实非常高效，但是如果使用不当则会导致各种严重的问题。诸如内存泄露这类问题，功能测试并没有异常，如果相关接口没有进行压测或者稳定性测试而直接上线，则会导致严重的线上问题。

内存池PooledByteBuf的使用建议：

1、申请之后一定要记得释放，Netty自身Socket读取和发送的ByteBuf系统会自动释放，用户不需要做二次释放；如果用户使用Netty的内存池在应用中做ByteBuf的对象池使用，则需要自己主动释放；

2、避免错误的释放：跨线程释放、重复释放等都是非法操作，要避免。特别是跨线程申请和释放，往往具有隐蔽性，问题定位难度较大；

3、防止隐式的申请和分配：之前曾经发生过一个案例，为了解决内存池跨线程申请和释放问题，有用户对内存池做了二次包装，以实现多线程操作时，内存始终由包装的管理线程申请和释放，这样可以屏蔽用户业务线程模型和访问方式的差异。谁知运行一段时间之后再次发生了内存泄露，最后发现原来调用ByteBuf的write操作时，如果内存容量不足，会自动进行容量扩展。扩展操作由业务线程执行，这就绕过了内存池管理线程，发生了“引用逃逸”。