Netty内存泄漏问题

ByteBuf分类、回收及使用场景

Netty中按是否使用了池化技术，ByteBuf分为两类，一类是非池化的ByteBuf，包括UnpooledHeapByteBuf、UnpooledDirectByteBuf等等，每次I/O读写都会创建一个新ByteBuf，频繁进行大块内存的分配和回收对性能有一定影响，非池化的ByteBuf可以通过JVM GC自动回收，也推荐手动回收UnpooledDirectByteBuf等使用堆外内存的ByteBuf；另一类是池化的ByteBuf，包括pooledHeapByteBuf、pooledDirectByteBuf等等，其先申请一块大内存池，在内存池中分配空间，对于这种应用级别的内存二次分配，就需要手动对池化的ByteBuf进行释放，否则就有可能出现内存泄露的问题。

ByteBuf 该如何选择: 一般业务数据的内存分配选用Java堆内存UnpooledHeapByteBuf，其实现简单，回收快，不会出现内存管理问题；对于I/O数据的内存分配一般选用池化的直接内存PooledDirectByteBuf，避免Java堆内存到直接内存的拷贝，但使用池化ByteBuf时切记自己分配的内存一定要在用完后手动释放。

Netty的接收和发送ByteBuf采用的DirectBuffers，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（heap buffers）进行socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入socket中。相比堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。

ByteBuf的计数器实现

那对于池化的ByteBuf在使用完释放回池中时，如何知道自己被引用多少次，并且在没有其他引用的时候被释放呢？ByteBuf的具备实现类都继承了AbstractReferenceCountedByteBuf类，该类实现了对计数器的操作功能。当某一操作使得ByteBuf的引用增加时，调用retain()函数，使计数器的值原子增加，当某一操作使得ByteBuf的引用减少时，调用release()函数，使计数器的值原子减少，减少到0便会触发回收操作。

ByteBuf计数器的调用场景

（1）当一个ByteBuf新建时，或从另一个ByteBuf创建出独立个体时（比如copy()，readBytes(int length))，新的ByteBuf在初始化的时候，自己的计数器也会初始化。这种ByteBuf使用结束后，要主动释放

（2）有些ByteBuf从另一个ByteBuf衍生出来时（比如decode()，retainedSlice(index, length)），底层共用同一个buffer，也会调用retain()函数，来使得计数器增加。使用完毕也要主动释放。

（3）有些ByteBuf从另一个ByteBuf衍生出来时（比如duplicate(), slice(), order()），底层与父类ByteBuf共用一个buffer，其没有自己的计数器，共用父类ByteBuf的计数器，计数器也不会增加。因此，如果要把这些衍生ByteBuf传递给其他函数时，必须要主动调用retain()函数，并在本函数释放父类ByteBuf，在下一个函数里释放衍生ByteBuf。如下面代码

java

ByteBuf parent = ctx.alloc().directBuffer(512);
parent.writeBytes(...);

try {
    while (parent.isReadable(16)) {
        ByteBuf derived = parent.readSlice(16);
        derived.retain();
        process(derived);
    }
} finally {
    parent.release();
}
...

public void process(ByteBuf buf) {
    ...
    buf.release();
}

以我遇到的内存泄漏的场景为例

（1）readBytes(int length)函数可能会调用到如下代码，新生成一个ByteBuf

java

@Override
protected PooledByteBuf<ByteBuffer> newByteBuf(int maxCapacity) {
    if (HAS_UNSAFE) {
        return PooledUnsafeDirectByteBuf.newInstance(maxCapacity);
    } else {
        return PooledDirectByteBuf.newInstance(maxCapacity);
    }
}

（2）ByteBuf in = (ByteBuf) super.decode(ctx,inByteBuf) 调用decode函数时，会调用到buffer.retainedSlice(index, length)函数，会返回原ByteBuf的一个片段，同时使原ByteBuf的计数器增加。它们底层共用同一个buffer，修改一个会影响另一个。

java

final <U extends AbstractPooledDerivedByteBuf> U init(
        AbstractByteBuf unwrapped, ByteBuf wrapped, int readerIndex, int writerIndex, int maxCapacity) {
    wrapped.retain(); // Retain up front to ensure the parent is accessible before doing more work.
    parent = wrapped;
    rootParent = unwrapped;
    ......
}

谁来释放ByteBuf

最基本的规则是谁最后访问ByteBuf，谁最后负责释放。需注意的是：

（1）发送组件将ByteBuf传递给接收组件，发送组件一般不负责释放，由接收组件释放；

（2）如果一个组件除了接收处理ByteBUf，而不做其他操作（比如再传给其他组件），这个组件负责释放ByteBuf。

例如

动作	谁应该释放？	谁释放了？
main() 创建 buf	buf→main()	main() 释放 buf
main() 调用 a() 并传入 buf	buf→a()	a() 释放 buf
a() 仅返回 buf	buf→main()	main() 释放 buf
main() 调用 b() 并传入 buf	buf→b()	b() 释放 buf
b() 返回 buf 的副本	buf→b()	b() 释放 buf，main() 释放副本
main() 调用 c() 并传入副本	copy→c()	c() 释放副本
c() 消耗副本	copy→c()	c() 释放副本

在 ChannelHandler负责链中，如何释放

Inbound messages

如果ChannelHandler中，只有处理ByteBuf的操作，不会调ctx.fireChannelRead(buf)把ByteBuf传递下去，那就要在这个ChannelHandler中释放ByteBuf。
如果ChannelHandler中，会调ctx.fireChannelRead(buf)把ByteBuf传递给下一个ChannelHandler，那在当前ChannelHandler中不需要释放ByteBuf，由最后一个使用该ByteBuf的ChannelHandler释放。
如果处理的ByteBuf是由decode()等会增加计数器的操作生成的，不再传递时，ByteBuf也要释放。
如果不确定要不要释放，或者简化释放的过程，可以调用ReferenceCountUtil.release(ByteBuf)函数。
也可以把ChannelHandler都承继自SimpleChannelInboundHandler虚类，该类会在channelRead函数中调用ReferenceCountUtil.release(msg)来帮助释放ByteBuf，如下代码所示，channelRead0(ctx, imsg)是一个虚函数，子类实现channelRead0函数用来完成处理逻辑。

java

@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    boolean release = true;
    try {
        if (acceptInboundMessage(msg)) {
            @SuppressWarnings("unchecked")
            I imsg = (I) msg;
            channelRead0(ctx, imsg);
        } else {
            release = false;
            ctx.fireChannelRead(msg);
        }
    } finally {
        if (autoRelease && release) {
            ReferenceCountUtil.release(msg);
        }
    }
}

Outbound messages

Outbound messages中的ByteBuf都是由应用程序产生的，由Netty负责释放。内存泄露检测

使用引用计数的缺点在于容易产生内存泄露，因为JVM不知道引用计数的存在。当一个对象不可达时，JVM可能会收回该对象，但这个对象的引用计数可能还不是0，这就导致该对象从池里分配的空间不能归还到池里，从而导致内存泄露。

Netty提供了一种内存泄露检测机制，可以通过配置参数不同选择不同的检测级别，参数设置为java -Dio.netty.leakDetection.level=advanced

DISABLED ：完全禁用内存泄露检测，不推荐
SIMPLE ：抽样1%的ByteBuf，提示是否有内存泄露
ADVANCED ：抽样1%的ByteBuf，提示哪里产生了内存泄露
PARANOID ：对每一个ByteBu进行检测，提示哪里产生了内存泄露

Netty内存泄漏问题 ​

ByteBuf分类、回收及使用场景 ​

ByteBuf的计数器实现 ​

ByteBuf计数器的调用场景 ​

在 ChannelHandler负责链中，如何释放 ​

Inbound messages ​

Outbound messages ​

Netty内存泄漏问题

ByteBuf分类、回收及使用场景

ByteBuf的计数器实现

ByteBuf计数器的调用场景

在 ChannelHandler负责链中，如何释放

Inbound messages

Outbound messages