netty系列之:netty 中的 ByteBuf 就是比 JAVA 中的好用

转
 2023-01-03
©版权
原文作者：程序那些事 原文地址：https://juejin.cn/post/7063778142711709727

简介

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中的对比。还不赶紧用起来。

本文已收录于 www.flydean.com/45-netty-by…

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

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