简介

netty作为一个优良的的NIO框架，被广泛应用于各种服务器和框架中。同样是NIO，netty所依赖的JDK在1.4版本中早就提供nio的包，既然JDK曾经有了nio的包，为什么netty还要再写一个呢？

不是因为JDK不优良，而是因为netty的要求有点高。

ByteBuf和ByteBuffer的可扩展性

在解说netty中的ByteBuf如何优良之前，咱们先来看一下netty中的ByteBuf和jdk中的ByteBuffer有什么关系。

事实上，没啥关系，只是名字长的有点像而已。

jdk中的ByteBuffer，全称是java.nio.ByteBuffer,属于JAVA nio包中的一个根底类。它的定义如下：

public abstract class ByteBuffer    extends Buffer    implements Comparable<ByteBuffer>

而netty中的ByteBuf，全称是io.netty.buffer,属于netty nio包中的一个根底类。它的定义如下：

public abstract class ByteBuf implements ReferenceCounted, Comparable<ByteBuf>

两者的定义都很相似，两者都是抽象类，都须要具体的类来实现他们。

然而，当你尝试去创立一个类来继承JDK的ByteBuffer，则会发现继承不了，为什么命名一个abstract的类会继承不了呢？

认真研究会发现，在ByteBuffer中，定义了上面两个没有显示标记其作用域拜访的办法：

    abstract byte _get(int i);                          // package-private    abstract void _put(int i, byte b);                  // package-private

依据JDK的定义，没有显示标记作用域的办法，默认其拜访拜访是package，当这两个办法又都是abstract的，所以只有同一个package的类能力继承JDK的ByteBuffer。

当然，JDK自身有5个ByteBuffer的实现，他们别离是DirectByteBuffer,DirectByteBufferR,HeapByteBuffer,HeapByteBufferR和MappedByteBuffer。

然而JDK限度了用户自定义类对ByteBuffer的扩大。尽管这样能够保障ByteBuffer类在应用上的安全性，然而同时也当初了用户需要的多样性。

既然JDK的ByteBuffer不能扩大，那么很天然的netty中的ByteBuf跟它就没有任何关系了。

netty中的ByteBuff是参考了JDK的ByteBuffer，并且做了很多有意义的晋升，让ByteBuff更加好用。

和JDK的ByteBuffer相比，netty中的ByteBuf并没有扩大的限度，你能够自在的对其进行扩大和批改。

不同的应用办法

JDK中的ByteBuffer和netty中的ByteBuff都提供了对各种类型数据的读写性能。

然而绝对于netty中的ByteBuff, JDK中的ByteBuffer应用其来比较复杂，因为它定义了4个值来形容ByteBuffer中的数据和应用状况，这四个值别离是：mark,position,limit和capacity。

  • capacity是它蕴含的元素数。 capacity永远不会为负且永远不会扭转。
  • limit是不应读取或写入的第一个元素的索引。 limit永远不会为负，也永远不会大于其容量。
  • position是要读取或写入的下一个元素的索引。 position永远不会为负，也永远不会大于其限度。
  • mark是调用 reset 办法时其地位将重置到的索引。 mark并不一定有值，但当它有值的时候，它永远不会是负的，也永远不会大于position。

下面4个值的关系是：

0 <= mark <= position <= limit <= capacity

而后JDK还提供了3个解决下面4个标记的办法：

  • clear : 将 limit设置为capacity，并将position设置为0,示意能够写入。
  • flip : 将 limit设置为以后地位，并将position设置为0.示意能够读取。
  • rewind : limit不变，将position设置为0,示意从新读取。

是不是头很大？

太多的变量，太多的办法，尽管当初你可能记得，然而过一段时间就会遗记到底该怎么正确应用JDK的ByteBuffer了。

和JDK不同的是，netty中的ByteBuff,只有两个index，别离是readerIndex 和 writerIndex 。

除了index之外，ByteBuff还提供了更加丰盛的读写API，不便咱们应用。

性能上的不同

对于JDK的java.nio.ByteBuffer来说，当咱们为其调配空间的时候，buffer中会被应用0来填充。尽管这些0可能会马上被真正有意义的值来进行替换。然而不可否认，填充的过程耗费了CPU和内存。

另外JDK的java.nio.ByteBuffer是依赖于垃圾回收器来进行回收的，然而咱们之前讲过了，ByteBuffer有两种内型，一种是HeapBuffer，这种类型是由JVM进行治理的，用垃圾回收器来进行回收是没有问题的。

然而问题在于还有一类ByteBuffer是DirectByteBuffer，这种Buffer是间接调配在内部内存上的，并不是由JVM来进行治理.通常来说DirectBuffer可能会存在较长的工夫，如果短时间调配大量的短生命周期的DirectBuffer,会导致这些Buffer来不及回收，从而导致OutOfMemoryError.

另外应用API来回收DirectBuffer的速度也不是那么快。

相对而言，netty中的ByteBuf应用的是本人治理的援用计数。当ByteBuf的援用计数归零的时候，底层的内存空间就会被开释，或者返回到内存池中。

咱们看一下netty中direct ByteBuff的应用：

ByteBufAllocator alloc = PooledByteBufAllocator.DEFAULT;ByteBuf buf = alloc.directBuffer(1024);...buf.release(); // 回收directBuffer

当然，netty这种本人治理援用计数也有一些毛病，可能会在pooled buffer被垃圾回收之后，pool中的buffer才返回，从而导致内存泄露。

还好，netty提供了4种检测援用计数内存泄露的办法，别离是：

  • DISABLED---禁用泄露检测
  • SIMPLE --默认的检测形式，占用1% 的buff。
  • ADVANCED - 也是1%的buff进行检测，不过这个选项会展现更多的泄露信息。
  • PARANOID - 检测所有的buff。

具体的检测选项如下：

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

总结

以上就是netty中优良的ByteBuff和JDK中的比照。还不连忙用起来。

本文已收录于 http://www.flydean.com/45-netty-bytebuf-bytebuffer/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

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