近日在使用Netty框架开发程序中出现了内存泄露的问题，百度加调试了一番，做个整理。
1. 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中。相比堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
2. ByteBuf的计数器实现
那对于池化的ByteBuf在使用完释放回池中时，如何知道自己被引用多少次，并且在没有其他引用的时候被释放呢？ByteBuf的具备实现类都继承了AbstractReferenceCountedByteBuf类，该类实现了对计数器的操作功能。当某一操作使得ByteBuf的引用增加时，调用retain()函数，使计数器的值原子增加，当某一操作使得ByteBuf的引用减少时，调用release()函数，使计数器的值原子减少，减少到0便会触发回收操作。关于AbstractReferenceCountedByteBuf类的源码分析，请见Netty框架AbstractReferenceCountedByteBuf 源码分析。
3. 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。如下面代码
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
@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，修改一个会影响另一个。
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; ...... }
4. 谁来释放ByteBuf
最基本的规则是谁最后访问ByteBuf，谁最后负责释放。需注意的是：
（1）发送组件将ByteBuf传递给接收组件，发送组件一般不负责释放，由接收组件释放；
（2）如果一个组件除了接收处理ByteBUf，而不做其他操作（比如再传给其他组件），这个组件负责释放ByteBuf。
例如
| Action | Who should release? |
Who released? |
1. main() creates buf |
buf→main() |
main() releases buf |
2. main() calls a() with buf |
buf→a() |
a() releases buf |
3. a() returns buf merely. |
buf→main() |
main() releases buf |
4. main() calls b() with buf |
buf→b() |
b() releases buf |
5. b() returns the copy of buf |
buf→b() |
b() releases buf, |
6. main() calls c() with copy |
copy→c() |
c() releases copy |
7. c() swallows copy |
copy→c() |
c() releases copy |
5. 在 ChannelHandler负责链中，如何释放
（1）在Inbound messages中
a. 如果ChannelHandler中，只有处理ByteBuf的操作，不会调ctx.fireChannelRead(buf)把ByteBuf传递下去，那就要在这个ChannelHandler中释放ByteBuf。
b. 如果ChannelHandler中，会调ctx.fireChannelRead(buf)把ByteBuf传递给下一个ChannelHandler，那在当前ChannelHandler中不需要释放ByteBuf，由最后一个使用该ByteBuf的ChannelHandler释放。
c. 如果处理的ByteBuf是由decode()等会增加计数器的操作生成的，不再传递时，ByteBuf也要释放。
d. 如果不确定要不要释放，或者简化释放的过程，可以调用ReferenceCountUtil.release(ByteBuf)函数。
e. 也可以把ChannelHandler都承继自SimpleChannelInboundHandler虚类，该类会在channelRead函数中调用ReferenceCountUtil.release(msg)来帮助释放ByteBuf，如下代码所示，channelRead0(ctx, imsg)是一个虚函数，子类实现channelRead0函数用来完成处理逻辑。
@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); } } }
（2）在Outbound messages中
Outbound messages中的ByteBuf都是由应用程序产生的，由Netty负责释放。
6. 内存泄露检测
使用引用计数的缺点在于容易产生内存泄露，因为JVM不知道引用计数的存在。当一个对象不可达时，JVM可能会收回该对象，但这个对象的引用计数可能还不是0，这就导致该对象从池里分配的空间不能归还到池里，从而导致内存泄露。
Netty提供了一种内存泄露检测机制，可以通过配置参数不同选择不同的检测级别，参数设置为java -Dio.netty.leakDetection.level=advanced
DISABLED：完全禁用内存泄露检测，不推荐SIMPLE：抽样1%的ByteBuf，提示是否有内存泄露ADVANCED：抽样1%的ByteBuf，提示哪里产生了内存泄露PARANOID：对每一个ByteBu进行检测，提示哪里产生了内存泄露
我在测试时，直接提示了ByteBuf内存泄露的位置，如下，找到自己程序代码，看哪里有新生成的ByteBuf对象没有释放，主动释放一下，调用对象的release()函数，或者用工具类帮助释放ReferenceCountUtil.release(msg)。
2020-06-12 17:04:41.242 [nioEventLoopGroup-2-1] ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information. Recent access records: Created at: io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:363) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187) io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:123) io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872) com.spring.netty.twg.service.TwgMessageDecoder.formatDecoder(TwgMessageDecoder.java:176) com.spring.netty.twg.service.TwgMessageDecoder.getMessageBody(TwgMessageDecoder.java:90) com.spring.netty.twg.service.TwgMessageDecoder.decode(TwgMessageDecoder.java:76) io.netty.handler.codec.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:332) io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501)
2020-06-12 17:04:45.460 [nioEventLoopGroup-2-1] ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information. Recent access records: Created at: io.netty.buffer.SimpleLeakAwareByteBuf.unwrappedDerived(SimpleLeakAwareByteBuf.java:143) io.netty.buffer.SimpleLeakAwareByteBuf.retainedSlice(SimpleLeakAwareByteBuf.java:57) io.netty.handler.codec.LengthFieldBasedFrameDecoder.extractFrame(LengthFieldBasedFrameDecoder.java:498) io.netty.handler.codec.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:437) com.spring.netty.twg.service.TwgMessageDecoder.decode(TwgMessageDecoder.java:31) io.netty.handler.codec.LengthFieldBasedFrameDecoder.decode(LengthFieldBasedFrameDecoder.java:332)
参考资料
https://netty.io/wiki/reference-counted-objects.html#who-destroys-it
https://blog.csdn.net/u013202238/article/details/93383887