Netty学习笔记（9）——Netty组件ByteBuf

Z时代
2024-01-10
分类：综合

1. ByteBuf作用

1. 当进行数据传输时，都会使用到一个缓冲区，在jdk提供的NIO中最常用的就是ByteBuffer，但在使用的时候，我们很容易会感到ByteBuffer有以下缺点：

ByteBuffer实际上就是一个Byte数组，所以在一开始进行创建时，就必须要指定其大小，而且不能进行动态扩容以及缩容，这就引起了很多问题，经常会导致数组下标越界异常。

ByteBuffer中有三个标示位，用于标示读写时的位置，所以在使用ByteBuffer进行读写时必须经常调用flip()方法来切换读写模式，否则就会导致程序异常。

ByteBuffer的API功能有限。

2. 为了弥补ByteBuffer的缺点，Netty中提供了ByteBuf类来取代NIO的ByteBuffer。其优点如下：

通过内置的复合缓冲区类型实现了透明的零拷贝；

容量可以按需增长（类似于 JDK 的 StringBuilder）；

在读和写这两种模式之间切换不需要调用 ByteBuffer 的 flip()方法；

读和写使用了不同的索引；

支持方法的链式调用；

支持引用计数；

支持池化；

它可以被用户自定义的缓冲区类型扩展；

ByteBuf并不是和ByteBuffer一样，是一个具体实现类，而是一个抽象类，我们可以通过继承该抽象类自己去实现所需要的缓冲区，当然，Netty中也提供了非常丰富的具体实现类，基本满足我们的使用需求。

2. 原理分析

1. 首先，ByteBuf肯定还是和ByteBuffer一样，底层都是一个Byte类型的数组，基本功能是与ByteBuffer一致的，也就是ByteBuffer有的API，ByteBuf里也有基本相同功能的API。但除此之外，为了弥补NIO中ByteBuffer的缺点，ByteBuf在ByteBuffer的基础上进行了一些扩展，扩展方式有两种

通过直接继承或者是直接赋值代码的方式，将基本功能的代码移植过来，然后再添加一些新的功能代码。

通过外观模式，也就是通过聚合的方式，对ByteBuffer进行包装，可以减少需要编写的代码量。基本上都是使用这种方式，外观模式的应用在这里有着体现，具体的ByteBuf实现类比如io.netty.buffer.ReadOnlyByteBuf等都是使用聚合的方式进行扩展ByteBuffer。

2. 为什么ByteBuf不需要进行读写状态切换：

其实原理很简单，在ByteBuffer中只用了一个position变量来记录标示当前操作的数组下标位置，所以读写需要切换状态；而在ByteBuf中则另外添加两个变量来记录读或写进行操作的当前数组下标，对应变量分别是readerIndex和writerIndex，而且必须满足readerIndex <= writerIndex。也就是说，读操作只会改变readerIndex变量，而写操作只会改变writerIndex，同时要满足满足readerIndex <= writerIndex，这样就能使得不需要进行读写状态切换。

3. API介绍

1. 读操作：ByteBuffer中通过相关的get方法来实现数据读取，上面说了，ByteBuf中有ByteBuffer的基本功能，所以也有ByteBuffer的get方法，但是ByteBuf还是扩展了相关的read方法，get方法的功能主要是通过下标index随机读取，而read方法实现的是顺序读取。

但是，尽管read方法和get方法的功能都是基本相同的，在底层原理上还是不同的，因为ByteBuf的get方法是直接调用ByteBuffer的get方法来实现的，所以其不会改变ByteBuf中的readerIndex变量，只会改变ByteBuffer中的position，必须要注意这一点。不能get方法和read方法混用，会出现问题。部分读操作API如下

2. 写操作：ByteBuf中的写操作是write方法，与ByteBuffer中的put方法类似，但是ByteBuf中并没有put方法，而是换成了set方法，set方法的功能主要是通过下标index随机写入数据，而write方法实现的是顺序写入数据。同样的，虽然write和set方法都可以想缓冲区插入数据，但是只有write方法可以操作改变writerIndex变量，而set方法则不可以。部分API如下

3. 可丢弃字节（discardReadBytes()方法），上面提到过，ByteBuf相较于ByteBuffer有一个改进就是可以动态扩容，其底层原理无非就是对于Byte数组进行扩容或缩容，但是这个操作是非常耗时的。为了提高性能，ByteBuf中还通过readerIndex索引变量实现了可丢弃字节的功能，也就是重复利用已读取过的数组空间。原理图如下

字节丢弃后

但是，discardReadBytes方法原理说白了就是内存复制，只不过比单纯的数组扩容的性能要好得多，因为数组扩容需要先进行开辟内存空间，然后再复制原数组中的每一个元素，而discardReadBytes方法只需要复制部分元素即可，但是频繁调用discardReadBytes方法仍然很耗费性能，所以如果不是必须的话，不建议执行。

4. 可读可写判断（isReadable方法和isWritable方法）：通过readerIndex 和 writerIndex，ByteBuf还提供了一个可读可写的判断操作，从Byte数组下标0处到readerIndex 之前都是读取过的数据，而readerIndex到writerIndex之间就是可以进行读取的数据空间，writerIndex到array.length-1之间就是可以写入的数据空间，所以很容易就可以实现一个可读可写的判断条件。

5. 读写索引管理：读写索引管理就是指调整改变readerIndex 和 writerIndex的值，除了读写操作以及discardReadBytes外，ByteBuf还提供了几个专门管理读写索引的方法

markReaderIndex()和resetReaderIndex()：标记当前读索引的位置，然后调用resetReaderIndex重置readerIndex 的值到该位置，这两个方法都是配套使用的

markWriterIndex()和resetWriterIndex()：标记当前写索引的位置，然后调用resetWriterIndex重置writerIndex的值到该位置，这两个方法都是配套使用的

clear()：清空缓冲区，这个方法虽说是清空缓冲区，但实际上只是重置读写索引的值为0，并不会将数组中的元素值为null，所以该方法性能很好。

6. 查找操作：有时候需要在缓冲区里查找某个byte数据，比如查找换行符字节等，ByteBuf提供了一系列的方法来实现

int indexOf(int fromIndex, int toIndex, byte value)：从起始索引fromIndex开始遍历，查询首次出现value的位置索引，终点索引是toIndex，没有找到则返回-1

int bytesBefore(byte value)：从readerIndex 到writerIndex之间查询首个出现value的索引下标，没有找到则返回-1

int bytesBefore(int length, byte value)：从readerIndex 到readerIndex +length之间查询首个出现value的索引下标，没有找到则返回-1，但要注意如果readerIndex +length大于writerIndex就会抛出数组下标越界异常。

int bytesBefore(int index, int length, byte value)：从index到index+length之间查询首个出现value的索引下标，没有找到则返回-1，如果index+length大于缓冲区数组长度，就会抛出数组下标越界异常。

int forEachByte(ByteBufProcessor processor)：从readerIndex 到writerIndex之间遍历满足ByteBufProcessor 查询条件的索引下标，没有找到则返回-1

int forEachByte(int index, int length, ByteBufProcessor processor)：从index到index+length之间查询首个满足ByteBufProcessor 查询条件的索引下标，没有找到则返回-1，如果index+length大于缓冲区数组长度，就会抛出数组下标越界异常。

int forEachByteDesc(ByteBufProcessor processor)：这个就是forEachByte的逆序查找版本

int forEachByteDesc(int index, int length, ByteBufProcessor processor)：forEachByte的逆序查找版本

7. 派生缓冲区：有多种方式

ByteBuf copy()：将当前的ByteBuf 复制一份，也就是说创建一个新的ByteBuf 对象，并且将其中的Byte数组内容一并被复制，而且读写索引变量不变，但是两个ByteBuf 之间互不影响，数据内容和读写索引都是独立的（不共享缓冲区内容）。

ByteBuf copy(int index, int length)：同上，但是是从指定的index下标位置卡死是复制length个字节，同样复制后的读写索引和内容都是独立的（不共享缓冲区内容）。

ByteBuf slice()：返回当前ByteBuf 对象的可读子缓冲区，也就是将readerIndex 到writerIndex之间的字节数据组裁剪复制一份出来，并且子缓冲区的读写索引独立维护，但是共享缓冲区的数据内容，也就是说，相当于两个ByteBuf 对象中的Byte数组对象是同一个，但是两个ByteBuf对象维护了各自的读写索引。

ByteBuf slice(int index, int length)：返回当前ByteBuf 对象的可读子缓冲区，范围从index到index+length，读写索引独立维护，但是共享数据内容。

ByteBuf duplicate()：完整复制当前的ByteBuf对象，共享整个缓冲区的数据内容，但是各自维护各自的读写索引。

8. 转换为NIO中的ByteBuffer：

ByteBuffer nioBuffer()：将当前ByteBuf 对象可读的缓冲区转换为ByteBuffer对象并返回，共享缓冲区内容，但各自维护的读写索引独立，而且ByteBuffer对象无法感知到ByteBuf对象中对于缓冲区的扩容操作。

ByteBuffer nioBuffer(int index, int length)：将当前ByteBuf 对象从index处到index+length的的缓冲区转换为ByteBuffer对象并返回，共享缓冲区内容，但各自维护的读写索引独立，而且ByteBuffer对象无法感知到ByteBuf对象中对于缓冲区的扩容操作。

4. ByteBuf的具体实现子类

ByteBuf的子类非常复杂，而且功能种类繁多，只列举几个示例。

1. 缓冲区内存分配模式分类：在NIO中说过缓冲区的内存分配方式有两种，一种是通过JVM的堆内存进行分配，比如ByteBuffer中的Byte数组，另一种则是直接通过物理内存空间（或者说系统内核空间）分配的，这种方式分配的特点就是其数据读写并不能以JVM中的数组形式进行，同样的Netty中也提供了ByteBuf的两种实现（直接内存和堆内存这里有一个零拷贝的相关知识点，后面详细讲解，其实通过这里基本也能知道什么是零拷贝）

堆内存分配：内存分配在JVM的堆中进行，由于是在JVM的堆中所以其内存分配和回收的速度都比较快，但缺点是相较于直接内存，需要额外的进行一次IO操作将数据在系统内核空间和用户空间之积进行复制移动，所以性能较差。（比如io.netty.buffer.PooledHeapByteBuf），以读操作为例

        ByteBuf heapByteBuf = Unpooled.wrappedBuffer(new byte[1024]);
        if(heapByteBuf.hasArray()) {//判断是否为堆内存分配的缓冲区，是则进行下面的操作
            byte[] array = heapByteBuf.array();//获取当前缓冲区的字节数组引用
            int offset = heapByteBuf.arrayOffset();//获取数组偏移量
            int length = heapByteBuf.readableBytes();//获取数组中的可读缓冲区字节数量
            //do something        }

直接内存分配：直接在系统内核空间进行内存分配，这种方式避免了需要额外的进行一次IO操作将数据在系统内核空间和用户空间之积进行复制移动，所以性能较高，但是内存的分配和回收清理比较慢。（比如io.netty.buffer.PooledDirectByteBuf），以读操作为例

        ByteBuf directByteBuf = Unpooled.directBuffer(1024);
        if(!directByteBuf.hasArray()) {//判断是否为直接内存分配的缓冲区，是则进行下面的操作
            int length = directByteBuf.readableBytes();//获取可读缓冲区的字节数
            byte[] array = new byte[length];
            directByteBuf.getBytes(directByteBuf.readerIndex(), array);//将直接内存缓冲区中的数据读取到array中
            //do something

因为这两种方式各有利弊，最佳应用应该是在IO通信线程中使用直接内存分配，而在数据消息的编解码等模块使用堆内存分配。

2. 内存回收模式分类：

类似于线程池的缓冲区ByteBuf对象池：和线程池的原理类似，作用也是一样的，ByteBuf缓存池中会存放多个ByteBuf对象，这些ByteBuf对象可以重复利用，减少了高高负载情况下的频繁的进行内存分配和回收。

普通ByteBuf：需要进行频繁的内存分配和回收，内存使用效率低。

使用ByteBuf对象池确实要比直接使用ByteBuf对象在性能上要好得多，但ByteBuf对象池的管理和维护非常复杂，代码中使用时必须要更加谨慎。

3. Netty中的Scatter/Gather机制实现：Netty中提供了一种复合缓冲区来实现NIO中的Scatter/Gather机制，复合缓冲区中存放并管理多个ByteBuf，可以在这个复合缓冲区增删ByteBuf对象。Netty中通过io.netty.buffer.CompositeByteBuf来实现了这个机制，它提供了一个将多个缓冲区合并表示为单个缓冲区的虚拟表示。

CompositeByteBuf中的ByteBuf对象可能同时包含直接内存分配和非直接内存分配两种。如果CompositeByteBuf只有一个ByteBuf实例，那么对 CompositeByteBuf 上的 hasArray()方法的调用将返回该组件上的hasArray()方法的值；否则它将返回 false。

CompositeByteBuf 总因为可能有直接内存分配的ByteBuf，所以其可能不支持访问其支撑数组，因此访问 CompositeByteBuf 中的数据类似于（访问）直接缓冲区的模式。