自顶向下深入分析Netty（九）--ByteBuf

Netty架构模式

在本节之前，该系列文章已经自顶向下分析了Netty的基本组件： EventLoop， Channel和 ChannelHandler，而本节将分析最后一个组件：字节缓冲区 ByteBuf，可认为是图中 subReactor与 read和 send之间的部分。

9.1 ByteBuf总述

引入缓冲区是为了解决速度不匹配的问题，在网络通讯中，CPU处理数据的速度大大快于网络传输数据的速度，所以引入缓冲区，将网络传输的数据放入缓冲区，累积足够的数据再送给CPU处理。

9.1.1 缓冲区的使用

ByteBuf是一个可存储字节的缓冲区，其中的数据可提供给ChannelHandler处理或者将用户需要写入网络的数据存入其中，待时机成熟再实际写到网络中。由此可知，ByteBuf有读操作和写操作，为了便于用户使用，该缓冲区维护了两个索引：读索引和写索引。一个ByteBuf缓冲区示例如下：

+-------------------+------------------+------------------+
| discardable bytes |  readable bytes  |  writable bytes  |
|                   |     (CONTENT)    |                  |
+-------------------+------------------+------------------+
|                   |                  |                  |
0      <=      readerIndex   <=   writerIndex    <=    capacity

可知，ByteBuf由三个片段构成：废弃段、可读段和可写段。其中，可读段表示缓冲区实际存储的可用数据。当用户使用readXXX()或者skip()方法时，将会增加读索引。读索引之前的数据将进入废弃段，表示该数据已被使用。此外，用户可主动使用discardReadBytes（）清空废弃段以便得到跟多的可写空间，示意图如下：

清空前：
    +-------------------+------------------+------------------+
    | discardable bytes |  readable bytes  |  writable bytes  |
    +-------------------+------------------+------------------+
    |                   |                  |                  |
    0      <=      readerIndex   <=   writerIndex    <=    capacity
清空后：
    +------------------+--------------------------------------+
    |  readable bytes  |    writable bytes (got more space)   |
    +------------------+--------------------------------------+
    |                  |                                      |
readerIndex (0) <= writerIndex (decreased)       <=       capacity

对应可写段，用户可使用writeXXX()方法向缓冲区写入数据，也将增加写索引。

9.1.2 读写索引的非常规使用

用户在必要时可以使用clear()方法清空缓冲区，此时缓冲区的写索引和读索引都将置0，但是并不清除缓冲区中的实际数据。如果需要循环使用一个缓冲区，这个方法很有必要。
此外，用户可以使用mark()和reset()标记并重置读索引和写索引。想象这样的情形：一个数据需要写到写索引为4的位置，之后的另一个数据才写0-3索引，此时可以先mark标记0索引，然后byteBuf.writeIndex(4)，写入第一个数据，之后reset重置，写入第二个数据。用户可根据不同的业务，合理使用这两个方法。
需要说明的一点是：用户使用toString(Charset)将缓冲区的字节数据转为字符串时，并不会增加读索引。另外，toString()只是覆盖Object的常规方法，仅仅表示缓冲区的常规信息，并不会转化其中的字节数据。

9.1.3 ByteBuf的底层及派生

容易想到ByteBuf缓冲区的底层数据结构是一个字节数组。从操作系统的角度理解，缓冲区的区别在于字节数组是在用户空间还是内核空间。如果位于用户空间，对于JAVA也就是位于堆，此时可使用JAVA的基本数据类型byte[]表示，用户可使用array()直接取得该字节数组，使用hasArray()判定该缓冲区是否是用户空间缓冲区。如果位于内核空间，JAVA程序将不能直接进行操作，此时可委托给JDK NIO中的直接缓冲区DirectByteBuffer由其操作内核字节数组，用户可使用nioBuffer()取得直接缓冲区，使用nioBufferCount()判定底层是否有直接缓冲区。
用户可在已有缓冲区上创建视图即派生缓冲区，这些视图维护各自独立的写索引、读索引以及标记索引，但他们和原生缓冲区共享想用的内部字节数据。创建视图即派生缓冲区的方法有：duplicate()，slice()以及slice(int,int)。如果想拷贝缓冲区，也就是说期望维护特有的字节数据而不是共享字节数据，此时可使用copy()方法。

9.2 ByteBuf VS ByteBuffer

也许你已经发现了ByteBuf和ByteBuffer在命名上有极大的相似性，JDK的NIO包中既然已经有字节缓冲区ByteBuffer 的实现，为什么Netty还要重复造轮子呢？一个很大的原因是：ByteBuffer对程序员并不友好。
考虑这样的需求，向缓冲区写入两个字节0x01和0x02，然后读取出这两个字节。如果使用ByteBuffer，代码是这样的：

    ByteBuffer buf = ByteBuffer.allocate(4);
    buf.put((byte) 1);
    buf.put((byte) 2);

    buf.flip(); // 从写模式切换为读模式
    System.out.println(buf.get());  // 取出0x01
    System.out.println(buf.get());  // 取出0x02

对于熟悉Netty的ByteBuf的你来说，或许只是多了一行buf.flip()用于将缓冲区从写模式却换为读模式。但事实并不如此，注意示例中申请了4个字节的空间，此时理应可以继续写入数据。不幸的是，如果再次调用buf.put((byte)3)，将抛出java.nio.BufferOverflowException。而要正确达到该目的，需要调用buf.clear()清空整个缓冲区或者buf.compact()清除已经读过的数据。
这个操作虽然有些繁琐，但并不是不能忍受，那么继续上个例子，考虑这样取数据的操作：

    buf.flip();
    System.out.println(buf.get(0));
    System.out.println(buf.get(1));
    
    System.out.println(buf.get());
    System.out.println(buf.get());

通过之前的分析，聪明的你也许已经发现get()操作会增加读索引，那么get(index)操作也会增加读索引吗？答案是：并不会，所以这个代码示例是正确的，将输出0 1 0 1的结果。什么？get()与get(0)居然是两个不一样的操作，前者会增加读索引而后者并不会。是的，可以掀桌子了。此外，get()的方法名本身就很有迷惑性，很自然的会认为与数组的get()一致，但是却有一个极大的副作用：增加索引，所以合理的名字应该是：getAndIncreasePosition。
又引入了一个新名词position，事实上ByteBuffer中并没有读索引和写索引的说法，这两个索引被统一称为position。在读写模式切换时，该值将会改变，正好与事实上的读索引与写索引对应。但愿这样的说法，并没有让你觉得头晕。
如果我们使用Netty的ByteBuf，感觉世界清静了很多：

    ByteBuf buf2 = Unpooled.buffer(4);
    buf2.writeByte(1);
    buf2.writeByte(2);

    System.out.println(buf2.readByte());
    System.out.println(buf2.readByte());
    buf2.writeByte(3);
    buf2.writeByte(4);

当然，如果不幸分配到了噩梦模式，必须使用ByteBuffer，那么谨记这四个步骤：

1. 写入数据到ByteBuffer
2. 调用flip()方法
3. 从ByteBuffer中读取数据
4. 调用clear()方法或者compact()方法