为了提升消息接收和发送性能,Netty针对ByteBuf的申请和释放采用池化技术,通过PooledByteBufAllocator可以创建基于内存池分配的ByteBuf对象,这样就避免了每次消息读写都申请和释放ByteBuf。由于ByteBuf涉及byte[]数组的创建和销毁,对于性能要求苛刻的系统而言,重用ByteBuf带来的性能收益是非常可观的。
内存池是一把双刃剑,如果使用不当,很容易带来内存泄漏和内存非法引用等问题,另外,除了内存池,Netty同时也支持非池化的ByteBuf,多种类型的ByteBuf功能存在一些差异,使用不当很容易带来各种问题。
业务路由分发模块使用Netty作为通信框架,负责协议消息的接入和路由转发,在功能测试时没有发现问题,转性能测试之后,运行一段时间就发现内存分配异常,服务端无法接收请求消息,系统吞吐量降为0。
1 路由转发服务代码
作为案例示例,对业务服务路由转发代码进行简化,以方便分析:
public class RouterServerHandler extends ChannelInboundHandlerAdapter {
static ExecutorService executorService = Executors.newSingleThreadExecutor();
PooledByteBufAllocator allocator = new PooledByteBufAllocator(false);
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf reqMsg = (ByteBuf)msg;
byte [] body = new byte[reqMsg.readableBytes()];
executorService.execute(()->{
//解析请求消息,做路由转发,代码省略
//转发成功,返回响应给客户端
ByteBuf respMsg = allocator.heapBuffer(body.length);
respMsg.writeBytes(body);//作为示例,简化处理,将请求返回
ctx.writeAndFlush(respMsg);
});
}
}
进行一段时间的性能测试之后,日志中出现异常,进程内存不断飙升,怀疑存在内存泄漏问题,如下图所示。
2 响应消息内存释放玄机
对业务ByteBuf申请相关代码进行排查,发现响应消息由业务线程创建,但是却没有主动释放,因此怀疑是响应消息没有释放导致的内存泄漏。因为响应消息使用的是PooledHeapByteBuf,如果发生内存泄漏,利用堆内存监控就可以找到泄漏点,通过Java VisualVM工具观察堆内存占用趋势,并没有发现堆内存发生泄漏,如下图所示。
对内存做快照,查看在性能压测过程中响应消息PooledUnsafeHeapByteBuf的实例个数,如下图所示,响应消息对象个数和内存占用都很少,排除内存泄漏嫌疑。
业务从内存池中申请了ByteBuf,但是却没有主动释放它,最后也没有发生内存泄漏,这究竟是什么原因呢?通过对Netty源码的分析,我们破解了其中