简介

为什么世界上有这么多 JAVA 的程序员呢？其中一个很重要的原因就是 JAVA 相对于 C++而言，不需要考虑对象的释放，一切都是由垃圾回收器来完成的。在崇尚简单的现代编程世界中，会 C++的高手越来越少，会 JAVA 的程序员越来越多。

JVM 的垃圾回收器中一个很重要的概念就是 Reference count，也就是对象的引用计数，用来控制对象是否还被引用，是否可以被垃圾回收。

netty 也是运行在 JVM 中的，所以 JVM 中的对象引用计数也适用于 netty 中的对象。这里我们说的对象引用指的是 netty 中特定的某些对象，通过对象的引用计数来判断这些对象是否还被使用，如果不再被使用的话就可以把它们（或它们的共享资源）返回到对象池（或对象分配器）。

这就叫做 netty 的对象引用计数技术，其中一个最关键的对象就是 ByteBuf。

ByteBuf 和 ReferenceCounted

netty 中的对象引用计数是从 4.X 版本开始的，ByteBuf 是其中最终要的一个应用,它利用引用计数来提高分配和释放性能.

先来看一下 ByteBuf 的定义：

public abstract class ByteBuf implements ReferenceCounted, Comparable<ByteBuf>

可以看到 ByteBuf 是一个抽象类，它实现了 ReferenceCounted 的接口。

ReferenceCounted 就是 netty 中对象引用的基础，它定义了下面几个非常重要的方法，如下所示：

int refCnt();
ReferenceCounted retain();
ReferenceCounted retain(int increment);
boolean release();
boolean release(int decrement);

其中 refCnt 返回的是当前引用个数，retain 用来增加引用，而 release 用来释放引用。

ByteBuf 的基本使用

刚分配情况下 ByteBuf 的引用个数是 1：

ByteBuf buf = ctx.alloc().directBuffer();assert buf.refCnt() == 1;

当调用他的 release 方法之后，refCnt 就变成了 0：

boolean destroyed = buf.release();assert destroyed;assert buf.refCnt() == 0;

当调用它的 retain 方法，refCnt 就会加一：

ByteBuf buf = ctx.alloc().directBuffer();assert buf.refCnt() == 1;buf.retain();assert buf.refCnt() == 2;

要注意的是，如果 ByteBuf 的 refCnt 已经是 0 了，就表示这个 ByteBuf 准备被回收了，如果再调用其 retain 方法，则会抛出 IllegalReferenceCountException:refCnt: 0, increment: 1

所以我们必须在 ByteBuf 还未被回收之前调用 retain 方法。

既然 refCnt=0 的情况下，不能调用 retain()方法，那么其他的方法能够调用吗？

我们来尝试调用一下 writeByte 方法：

        try {            buf.writeByte(10);        } catch (IllegalReferenceCountException e) {            log.error(e.getMessage(),e);        }

可以看到，如果 refCnt=0 的时候，调用它的 writeByte 方法会抛出 IllegalReferenceCountException 异常。

这样看来，只要 refCnt=0，说明这个对象已经被回收了，不能够再使用了。

ByteBuf 的回收

既然 ByteBuf 中保存的有 refCnt，那么谁来负责 ByteBuf 的回收呢？

netty 的原则是谁消费 ByteBuf，谁就负责 ByteBuf 的回收工作。

在实际的工作中，ByteBuf 会在 channel 中进行传输，根据谁消费谁负责销毁的原则，接收 ByteBuf 的一方，如果消费了 ByteBuf，则需要将其回收。

这里的回收指的是调用 ByteBuf 的 release()方法。

ByteBuf 的衍生方法

ByteBuf 可以从一个 parent buff 中衍生出很多子 buff。这些子 buff 并没有自己的 reference count,它们的引用计数是和 parent buff 共享的，这些提供衍生 buff 的方法有：ByteBuf.duplicate(), ByteBuf.slice() 和 ByteBuf.order(ByteOrder)。

buf = directBuffer();        ByteBuf derived = buf.duplicate();        assert buf.refCnt() == 1;        assert derived.refCnt() == 1;

因为衍生的 byteBuf 和 parent buff 共享引用计数，所以如果要将衍生的 byteBuf 传给其他的流程进行处理的话，需要调用 retain()方法：

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();}

ChannelHandler 中的引用计数

netty 根据是读消息还是写消息，可以分为 InboundChannelHandler 和 OutboundChannelHandler,分别用来读消息和写消息。

根据谁消费，谁释放的原则，对 Inbound 消息来说，读取完毕之后，需要调用 ByteBuf 的 release 方法：

public void channelRead(ChannelHandlerContext ctx, Object msg) {    ByteBuf buf = (ByteBuf) msg;    try {        ...    } finally {        buf.release();    }}

但是如果你只是将 byteBuf 重发到 channel 中供其他的步骤进行处理，则不需要 release：

public void channelRead(ChannelHandlerContext ctx, Object msg) {    ByteBuf buf = (ByteBuf) msg;    ...    ctx.fireChannelRead(buf);}

同样的在 Outbound 中，如果只是简单的重发，则不需要 release：

public void write(ChannelHandlerContext ctx, Object message, ChannelPromise promise) {    System.err.println("Writing: " + message);    ctx.write(message, promise);}

如果是处理了消息，则需要 release：

public void write(ChannelHandlerContext ctx, Object message, ChannelPromise promise) {    if (message instanceof HttpContent) {        // Transform HttpContent to ByteBuf.        HttpContent content = (HttpContent) message;        try {            ByteBuf transformed = ctx.alloc().buffer();            ....            ctx.write(transformed, promise);        } finally {            content.release();        }    } else {        // Pass non-HttpContent through.        ctx.write(message, promise);    }}

内存泄露

因为 reference count 是 netty 自身来进行维护的，需要在程序中手动进行 release,这样会带来一个问题就是内存泄露。因为所有的 reference 都是由程序自己来控制的，而不是由 JVM 来控制，所以可能因为程序员个人的原因导致某些对象 reference count 无法清零。

为了解决这个问题，默认情况下，netty 会选择 1%的 buffer allocations 样本来检测他们是否存在内存泄露的情况.

如果发生泄露，则会得到下面的日志：

LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call ResourceLeakDetector.setLevel()

上面提到了一个检测内存泄露的 level，netty 提供了 4 种 level，分别是：

• DISABLED---禁用泄露检测

• SIMPLE --默认的检测方式，占用 1% 的 buff。

• ADVANCED - 也是 1%的 buff 进行检测，不过这个选项会展示更多的泄露信息。

• PARANOID - 检测所有的 buff。

具体的检测选项如下：

java -Dio.netty.leakDetection.level=advanced ...

总结

掌握了 netty 中的引用计数，就掌握了 netty 的财富密码！

本文的例子可以参考：learn-netty4

本文已收录于 http://www.flydean.com/43-netty-reference-cound/

最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！

欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！