共计 4120 个字符,预计需要花费 11 分钟才能阅读完成。
简介
为什么世界上有这么多 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/
最艰深的解读,最粗浅的干货,最简洁的教程,泛滥你不晓得的小技巧等你来发现!
欢送关注我的公众号:「程序那些事」, 懂技术,更懂你!