简介

为什么世界上有这么多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/
最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！
欢送关注我的公众号:「程序那些事」,懂技术，更懂你！