缓冲

最常用的模式是 ByteBuf 将数据存储在 JVM 的堆空间，这是通过将数据存储在数组的实现。堆缓冲区可以快速分配，当不使用时也可以快速释放。它还提供了直接访问数组的方法，通过 ByteBuf.array() 来获取 byte[]数据。 这种方法，正如清单5.1中所示的那样，是非常适合用来处理遗留数据的

ByteBuf heapBuf = ...;
if (heapBuf.hasArray()) {                //1 检查 ByteBuf 是否有支持数组
    byte[] array = heapBuf.array();        //2 如果有的话，得到引用数组
    int offset = heapBuf.arrayOffset() + heapBuf.readerIndex();                //3 计算第一字节的偏移量
    int length = heapBuf.readableBytes(); //4 获取可读的字节数
    handleArray(array, offset, length); //5 使用数组，偏移量和长度作为调用方法的参数
}

注意：

• 访问非堆缓冲区 ByteBuf 的数组会导致UnsupportedOperationException， 可以使用 ByteBuf.hasArray()来检查是否支持访问数组
• 这个用法与 JDK 的 ByteBuffer 类似

直接缓冲区 是另一个 ByteBuf 模式。对象的所有内存分配发生在堆？好吧，并非总是如此。在 JDK1.4 中被引入 NIO 的ByteBuffer 类允许 JVM 通过本地方法调用分配内存，其目的是：

• 通过免去中间交换的内存拷贝，提升IO处理速度，直接缓冲区的内容可以驻留在垃圾回收扫描的堆区以外
• DirectBuffer 在 -XX:MaxDirectMemorySize=xxM大小限制下, 使用 Heap 之外的内存, GC对此无能为力，也就意味着规避了在高负载下频繁的GC过程对应用线程的中断影响

这就解释了为什么 直接缓冲区 对于那些通过 socket 实现数据传输的应用来说，是一种非常理想的方式。如果你的数据是存放在堆中分配的缓冲区，那么实际上，在通过 socket 发送数据之前，JVM 需要将先数据复制到直接缓冲区

但是直接缓冲区的缺点是在内存空间的分配和释放上比堆缓冲区更复杂，另外一个缺点是如果要将数据传递给遗留代码处理，因为数据不是在堆上，你可能不得不作出一个副本，如下：

ByteBuf directBuf = ...
    if (!directBuf.hasArray()) {            //1 检查 ByteBuf 是不是由数组支持。如果不是，这是一个直接缓冲区
        int length = directBuf.readableBytes(); //2 获取可读的字节数
        byte[] array = new byte[length];    //3 分配一个新的数组来保存字节
        directBuf.getBytes(directBuf.readerIndex(), array);        //4 字节复制到数组
        handleArray(array, 0, length);  //5 将数组，偏移量和长度作为参数调用某些处理方法
    }

显然，这比使用数组要多做一些工作。因此，如果事前就知道容器里的数据将作为一个数组被访问，可能更愿意使用堆内存

最后一种模式是复合缓冲区，可以创建多个不同的 ByteBuf，然后提供一个这些 ByteBuf 组合的视图。复合缓冲区就像一个列表，可以动态的添加和删除其中的 ByteBuf，JDK 的 ByteBuffer 没有这样的功能

Netty 提供了 ByteBuf 的子类 CompositeByteBuf 类来处理复合缓冲区，CompositeByteBuf 只是一个视图

CompositeByteBuf.hasArray() 总是返回 false，因为它可能既包含堆缓冲区，也包含直接缓冲区

例如，一条消息由 header 和 body 两部分组成，将 header 和 body 组装成一条消息发送出去，可能 body 相同，只是 header 不同，使用CompositeByteBuf 就不用每次都重新分配一个新的缓冲区。下图显示CompositeByteBuf 组成 header 和 body：

下面代码显示了使用 JDK 的 ByteBuffer 的一个实现。两个 ByteBuffer 的数组创建保存消息的组件，第三个创建用于保存所有数据的副本：

// 使用数组保存消息的各个部分
ByteBuffer[] message = { header, body };

// 使用副本来合并这两个部分
ByteBuffer message2 = ByteBuffer.allocate(
    header.remaining() + body.remaining());
message2.put(header);
message2.put(body);
message2.flip();

这种做法显然是低效的：分配和复制操作不是最优的方法，操纵数组使代码显得很笨拙

下面看使用 CompositeByteBuf 的改进版本：

CompositeByteBuf messageBuf = ...;
ByteBuf headerBuf = ...; // 可以支持或直接
ByteBuf bodyBuf = ...; // 可以支持或直接
messageBuf.addComponents(headerBuf, bodyBuf); //1 追加 ByteBuf 实例的 CompositeByteBuf 
messageBuf.removeComponent(0);   //2 删除索引1的 ByteBuf

for (int i = 0; i < messageBuf.numComponents(); i++) {                        //3 遍历所有 ByteBuf 实例
    System.out.println(messageBuf.component(i).toString());
}

简单地把 CompositeByteBuf 当作一个可迭代遍历的容器。 CompositeByteBuf 不允许访问其内部可能存在的支持数组，也不允许直接访问数据，这一点类似于直接缓冲区模式。想要读取数据，需要如下面代码所示：

CompositeByteBuf compBuf = ...;
int length = compBuf.readableBytes();    //1 得到的可读的字节数
byte[] array = new byte[length];        //2 分配一个新的数组,数组长度为可读字节长度
compBuf.getBytes(compBuf.readerIndex(), array);    //3 读取字节到数组
handleArray(array, 0, length);    //4 使用数组，把偏移量和长度作为参数

Netty 尝试使用 CompositeByteBuf 优化 socket I/O 操作，消除原生 JDK 中可能存在的的性能低和内存消耗问题。虽然这是在 Netty 的核心代码中进行的优化，并且是不对外暴露的，但是作为开发者还是应该意识到其影响

ByteBuf 使用从0开始的索引，第一个字节的索引是 0，最后一个字节的索引是 ByteBuf 的 capacity - 1，下面代码是遍历 ByteBuf 的所有字节：

ByteBuf buffer = ...;

for (int i = 0; i < buffer.capacity(); i++) {
    byte b = buffer.getByte(i);
    System.out.println((char) b);
}

注意：通过索引访问时不会推进 readerIndex 和 writerIndex，我们可以通过 ByteBuf 的 readerIndex(index) 或 writerIndex(index) 来分别推进读索引或写索引

ByteBuf 提供两个指针变量支付读和写操作，读操作是使用 readerIndex()，写操作时使用 writerIndex()。这和JDK的ByteBuffer不同，ByteBuffer只有一个方法来设置索引，所以需要使用 flip() 方法来切换读和写模式

ByteBuf 一定符合：0 <= readerIndex <= writerIndex <= capacity

1. 字节，可以被丢弃，因为它们已经被读
2. 还没有被读的字节是： readable bytes（可读字节）
3. 空间可加入多个字节的是： writeable bytes（写字节）

在 JDK 的 InputStream 定义了 mark(int readlimit) 和 reset()方法。这些是分别用来标记流中的当前位置和复位流到该位置

同样，可以设置和重新定位ByteBuf readerIndex 和 writerIndex 通过调用 markReaderIndex(), markWriterIndex(), resetReaderIndex() 和 resetWriterIndex()。这些类似于InputStream 的调用，所不同的是，没有 readlimit 参数来指定当标志变为无效

可以通过调用 readerIndex(int) 或 writerIndex(int) 将指标移动到指定的位置。在尝试任何无效位置上设置一个索引将导致 IndexOutOfBoundsException 异常

调用 clear() 可以同时设置 readerIndex 和 writerIndex 为 0。注意，这不会清除内存中的内容。调用之前，包含3个段，下面显示了调用之后：

现在整个 ByteBuf 空间都是可写的了。clear() 比 discardReadBytes() 更低成本，因为他只是重置了索引，而没有内存拷贝

有几种方法，以确定在所述缓冲器中的指定值的索引。最简单的是使用 indexOf() 方法。更复杂的搜索执行以 ByteBufProcessor 为参数的方法。这个接口定义了一个方法，boolean process(byte value)，它用来报告输入值是否是一个正在寻求的值

ByteBufProcessor 定义了很多方便实现共同目标值。例如，假设您的应用程序需要集成所谓的“Flash sockets”，将使用 NULL 结尾的内容：

int index=buffer.forEachByte（ByteBufProcessor.FIND_NUL）;

通过减少的，因为少量的 边界检查 的处理过程中执行了，从而使 消耗 Flash 数据变得 编码工作量更少、效率更高

下面例子展示了寻找一个回车符 \r的一个例子：

ByteBuf buffer = ...;
int index = buffer.forEachByte(ByteBufProcessor.FIND_CR);

衍生的缓冲区 是代表一个专门的展示 ByteBuf 内容的 视图 。这种视图是由 duplicate(), slice(), slice(int, int), readOnly() 和 order(ByteOrder) 方法创建的。所有这些都返回一个新的 ByteBuf 实例包括它自己的 reader, writer 和标记索引。然而，内部数据存储共享就像在一个 NIO 的 ByteBuffer。这使得衍生的缓冲区创建、修改其 内容，以及修改其 源 实例更廉价

读/写操作主要由2类：

• get()/set() ：操作从给定的索引开始，保持不变
• read()/write()： 操作从给定的索引开始，与字节访问的数量来适用，递增当前的写索引或读索引

下表是常见的 get() 操作：

常见 set() 操作如下：

下面是 get 和 set 的实例：

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);    //1 创建一个新的 ByteBuf 给指定 String 保存字节
System.out.println((char)buf.getByte(0));                    //2 打印的第一个字符，N

int readerIndex = buf.readerIndex();                        //3 存储当前 readerIndex 和 writerIndex
int writerIndex = buf.writerIndex();

buf.setByte(0, (byte)'B');                            //4 更新索引 0 的字符B

System.out.println((char)buf.getByte(0));                    //5 打印出的第一个字符，现在B
assert readerIndex == buf.readerIndex();                    //6 这些断言成功，因为这些操作永远不会改变索引
assert writerIndex ==  buf.writerIndex();

下面展示了常见的 read() 方法：

每个 read() 方法都对应一个 write()：

下面是 read 和 write 的实例：

Charset utf8 = Charset.forName("UTF-8");
ByteBuf buf = Unpooled.copiedBuffer("Netty in Action rocks!", utf8);    //1 创建一个新的 ByteBuf 保存给定 String 的字节
System.out.println((char)buf.readByte());                    //2 打印的第一个字符 N

int readerIndex = buf.readerIndex();                        //3 存储当前的 readerIndex
int writerIndex = buf.writerIndex();                        //4 保存当前的 writerIndex

buf.writeByte((byte)'B');                            //5 更新索引0的字符 B

assert readerIndex == buf.readerIndex(); 
assert writerIndex != buf.writerIndex(); //6 此断言成功，因为 writeByte() 在 5 移动了 writerIndex

为了减少分配和释放内存的开销，Netty 通过支持池类 ByteBufAllocator，可用于分配的任何 ByteBuf 我们已经描述过的类型的实例。是否使用池是由应用程序决定的，表5.8列出了 ByteBufAllocator 提供的操作：

通过一些方法接受整型参数允许用户指定 ByteBuf 的初始和最大容量值。你可能还记得，ByteBuf 存储可以扩大到其最大容量

得到一个 ByteBufAllocator 的引用很简单。你可以得到从 Channel ，或通过绑定到的 ChannelHandler 的 ChannelHandlerContext 得到它，用它实现了数据处理逻辑

下面的代码说明获得 ByteBufAllocator 的两种方式：

Channel channel = ...;
ByteBufAllocator allocator = channel.alloc(); //1 从 channel 获得 ByteBufAllocator
....
ChannelHandlerContext ctx = ...;
ByteBufAllocator allocator2 = ctx.alloc(); //2 从 ChannelHandlerContext 获得 ByteBufAllocator
...

Netty 提供了两种 ByteBufAllocator 的实现：

• PooledByteBufAllocator，用ByteBuf 实例池改进性能以及内存使用降到最低，此实现使用一个 jemalloc 内存分配
• 不池化 ByteBuf 情况下，每次返回一个新的实例

Netty 默认使用 PooledByteBufAllocator，可以通过 ChannelConfig 或通过引导设置一个不同的实现来改变

ByteBufUtil 静态辅助方法来操作 ByteBuf，因为这个 API 是通用的，与使用池无关，这些方法已经在外面的分配类实现

最有价值的是 hexDump() 方法，这个方法返回指定 ByteBuf 中可读字节的十六进制字符串，可以用于调试程序时打印 ByteBuf 的内容。一个典型的用途是记录一个 ByteBuf 的内容进行调试。十六进制字符串相比字节而言对用户更友好。 而且十六进制版本可以很容易地转换回实际字节表示

另一个有用方法是使用 boolean equals(ByteBuf, ByteBuf),用来比较 ByteBuf 实例是否相等。在实现自己 ByteBuf 的子类时经常用到