首页 > 代码库 > Netty(7)源码-ByteBuf

Netty(7)源码-ByteBuf

一、ByteBuf工作原理

1. ByteBuf是ByteBuffer的升级版:

jdk中常用的是ByteBuffer,从功能角度上,ByteBuffer可以完全满足需要,但是有以下缺点:

  • ByteBuffer一旦分配完成,长度固定,不能动态扩展和收缩,当需要编码的POJO对象大于分配容量时发生索引越界异常
  • ByteBuffer只要一个标识位置的指针postion,读写切换比较麻烦,flip rewind等操作
  • 功能有限

ByteBuf依然是Byte数组缓冲区,拥有ByteBuffer的一切功能:

  • 7种Java基础类型、byte数组、ByteBuffer(ByteBuf)等读写;
  • 缓冲区自身的copy和slice等;
  • 设置网络字节序;
  • 构造缓冲区实例;
  • 操作位置指针方法;

2. ByteBuf的工作原理:

ByteBuf使用2个位置指针来协助缓冲区的读写操作,读操作使用readerIndex,写操作使用writerIndex。

(1) 一开始readerIndexwriterIndex都是0

(2) 随着写入writerIndex增加,随着读取readerIndex增加,但是不会超过writerIndex

(3) 读取之后,0~readerIndex这部分视为discard,调用discardReadBytes方法,可以释放这部分空间

(4) readerIndexwriterIndex之间的数据是可以读取的,等价于ByteBufferposition-limit之间的数据

(5) writerIndexcapacity之间的空间是可写的,等价于ByteBuffer limitcapacity之间的可用空间。

3. 用图演示上述过程:

初始分配的ByteBuf:

技术分享

 

 写入了N个字节之后:

技术分享

 

读取了M(<N)个字节之后的ByteBuf如图所示:

技术分享

调用了discardReadBytes操作之后的ByteBuf如图所示:

技术分享

调用了clear之后的ByteBuf如图所示:

技术分享

4. 动态扩展

跟大多数的自动扩容数组一样,在进行put操作的时候,如果空间不足,就创建新的ByteBuffer实现自动扩容,并将之前的ByteBuffer复制到新的ByteBuffer中,最后释放老的ByteBuffer。

    public ByteBuf writeBytes(ByteBuffer src) {        ensureAccessible();        int length = src.remaining();        ensureWritable(length);        setBytes(writerIndex, src);        writerIndex += length;        return this;    }

注意到读写都是使用ByteBuffer,在容量不足的时候会自动扩容:

    private void ensureWritable0(int minWritableBytes) {        if (minWritableBytes <= writableBytes()) {            return;        }        if (minWritableBytes > maxCapacity - writerIndex) {            throw new IndexOutOfBoundsException(String.format(                    "writerIndex(%d) + minWritableBytes(%d) exceeds maxCapacity(%d): %s",                    writerIndex, minWritableBytes, maxCapacity, this));        }        // Normalize the current capacity to the power of 2.        int newCapacity = alloc().calculateNewCapacity(writerIndex + minWritableBytes, maxCapacity);        // Adjust to the new capacity.        capacity(newCapacity);    }

二、ByteBuf功能介绍

1. 顺序读操作

  详见api,类似于ByteBuffer的get

2. 顺序写操作

  详见api,类似于ByteBuffer的put

3. readerIndex和writerIndex

读索引和写索引,将ByteBuf分割为3个区域:

技术分享

可读区域和可写区域,以及已经读取过的区域,可以调用discardReadBytes操作来重用这部分的空间,以节省内存,防止ByteBuf的动态扩张。这在私有协议栈解码的时候非常有用,因为TCP层可能会粘包,几百个整包消息被TCP作为一个整包发送。这样,使用discardReadBytes操作可以重用之前的已经解码过的缓冲区,从而防止接收缓冲区因为容量不足扩张。

但是,discardReadBytes是把双刃剑,不能滥用。

4. Discardable bytes

动态扩张比较耗时,因此为了提高性能,往往需要最大努力提升缓冲区的重用率。

discardbytes操作则可以重用已经读过的空间,减少扩容的次数。

但是,discardbytes操作本身也是自己数组的内存复制,所以频繁调用也会导致性能下降,因此调用之前,请确认,你想要时间换取空间,而不是扩容。

    @Override    public ByteBuf discardReadBytes() {        ensureAccessible();        if (readerIndex == 0) {            return this;        }        if (readerIndex != writerIndex) {            setBytes(0, this, readerIndex, writerIndex - readerIndex);            writerIndex -= readerIndex;            adjustMarkers(readerIndex);            readerIndex = 0;        } else {            adjustMarkers(readerIndex);            writerIndex = readerIndex = 0;        }        return this;    }

5. Readable bytes和Writable bytes

  • 可读区域中是数据实际存储的区域,以read或者skip开头的任何操作都将会从readerIndex开始读取或者跳过指定的数据。如果读的字节数>可读字节数,throw IndexOutOfBoundsException。
  • 可写区域是尚可填充的空间,任何以write开头的操作都会从writeIndex开始向空闲空间开始写入字节,如果写入字节数>可写字节数,也会抛出IndexOutOfBoundsException。

6. Clear操作

ByteBuffer的clear操作不会操作内容本身,而是修改指针位置。ByteBuf也一样,clear之后0=readerIndex=writerIndex。

7. Mark和Reset

某些情况需要能够回滚,Netty提供了类似的方法。

  • markReaderIndex:将当前的readerIndex备份到markedReaderIndex中;
  • resetReaderIndex:将当前的readerIndex设置为mardedReaderIndex;
  • markWriterIndex:将当前的readerIndex备份到markedWriterIndex中;
  • resetWriterIndex:将当前的readerIndex设置为mardedWriterIndex;

8. 查找操作

ByteBuf提供了查找方法用于满足不同的应用场景,详细分类如下.

(1) indexOf(int fromIndex, int toIndex, byte value):从from到to查找value的值

(2) bytesBefore(byte value): readerIndex到writerIndex中查找value的值

(3) bytesBefore(int length, byte value):从readerIndex到readerIndex+length

(4) bytesBefore(int index, int length, byte value): 从index到Index+length

(5) forEachByte(ByteBufProcessor processor): 遍历可读字节数组,与ByteBufProcessor 设置的条件进行对比

(6) forEachByte(int index, int length, ByteBufProcessor processor): 类似上面

(7) forEachByteDesc(ByteBufProcessor processor): 同上,采用逆序

(8) forEachByteDesc(int index, int length, ByteBufProcessor processor):逆序

对于被查询的字节,Netty在ByteBufProcessor中做好了抽象,定义如下:

  • FIND_NUL: NUL(0x00)
  • FIND_CR
  • FIND_LF
  • FIND_CRLF
  • FIND_LINER_WHITESPACE

9. Derived buffers

类似于数据库的视图。以下方法用于创建视图或者恢复ByteBuf。

(1) duplicate: 返回当前ByteBuf的复制对象,二者共享缓冲区内容,但是读写索引独立,即修改内容内容会变,索引变化不影响原ByteBuf。

(2) copy: 复制一个对象,不共享,内容和索引都是独立的;

(3) copy(int index, int length)

(4) slice: 返回当前ByteBuf的可读子缓冲区,即从readerIndex到writerIndex的部分,共享内容,索引独立。

(5) slice(int index, int length):共享内容,索引独立。

10. 转换为ByteBuffer

(1) ByteBuffer nioBuffer(): 当前可读缓冲区转换为ByteBuffer,共享内容,索引独立,且无法感知动态扩容;

(2) ByteBuffer nioBuffer(int index, int length)

11. 随机读写 (set和get)

随机读api:

技术分享

随机写api,同样方式可以查看。

无论是get还是set,都会对其索引进行合法性校验。

但是,set不支持动态扩展

三、源码分析

3.1 主要类继承关系

除了这些类之外,还有非常多的类:

技术分享

1. 从内存分配的角度有2类:

(1) 堆内存:优点是内存的分配和回收速度快,可以被自动回收,缺点是如果进行SocketIO的读写,需要额外一次的内存复制,将堆内存对应的缓冲区复制到内核Channel中,性能有一定程度损失。

(2) 直接内存:在堆外进行分配,相对分配和回收速度会慢一些,但是将它写入或者从Socket Channel读取时,少了一次内存复制,速度更快。

经验表明:ByteBuf的最佳实践是在I/O通信线程读写缓冲区使用DirectByteBuf,后端业务消息的编解码模块使用HeapByteBuf,这样组合可以达到性能最优。

2. 从内存回收角度上:

(1) 基于对象池的ByteBuf:内存池,可以循环创建ByteBuf,提升内存的利用率,降低高负载导致的频繁GC。

(2) 普通ByteBuf。

测试表明高负载使用内存池会更加的平稳。

尽管推荐使用基于内存池的ByteBuf,但是内存池的管理和维护更加复杂,也需要更加谨慎。

3.2 AbstactByteBuf

骨架类

1. 主要成员变量

    private static final boolean checkAccessible;    static {        checkAccessible = SystemPropertyUtil.getBoolean(PROP_MODE, true);        if (logger.isDebugEnabled()) {            logger.debug("-D{}: {}", PROP_MODE, checkAccessible);        }    }    static final ResourceLeakDetector<ByteBuf> leakDetector =            ResourceLeakDetectorFactory.instance().newResourceLeakDetector(ByteBuf.class);    //读索引    int readerIndex;    //写索引    int writerIndex;    private int markedReaderIndex;    private int markedWriterIndex;    private int maxCapacity;

一些公共属性的定义,这里关注下leakDetector:用于检测对象是否有泄露。

2. 读操作系列

这里没有定义缓冲区的实现,因为不知道是直接内存还是堆内存,但是无论是基于何种内存实现读操作,一些基本的操作都在骨架类中已经实现,实现代码复用,这也是抽象和继承的价值所在。

这里以方法readBytes为例:

    @Override    public ByteBuf readBytes(byte[] dst, int dstIndex, int length) {       //1. 检测缓冲区可读长度        checkReadableBytes(length);       //2. 抽象获取,由子类实现        getBytes(readerIndex, dst, dstIndex, length);       //3. 读索引增加        readerIndex += length;        return this;    }

检测长度方法非常简单,检测可读长度是否有length,这里略过。

3. 写操作系列

与读类似

    @Override    public ByteBuf writeBytes(byte[] src, int srcIndex, int length) {        ensureAccessible();        //1 .检测写长度合法        ensureWritable(length);        //2. 抽象方法,由子类实现        setBytes(writerIndex, src, srcIndex, length);        //3. 写索引增加        writerIndex += length;        return this;    }

为什么需要动态扩展?

  很多时候都是依据经验来判断Pojo对象的大小,如果这个估计值偏大则造成内存浪费,如果偏小直接抛出异常,这种做法对用户非常不友好。

  而Netty的ByteBuf支持动态扩展,为了保证安全,可以指定最大容量。

如何进行计算?

  参数是writerIndex+minWriableBytes,即满足要求的最小容量。

  设置阀门值是4MB,如果新增的内存空间大于这个值,不采用倍增,而采用每次步进4MB的方式,每次增加后和maxCapacity比较,选择其小者。

  如果扩容之后的新容量小于阀值,则以64进行倍增

这样做的原因无非是综合2点因素:不希望一次增加容量太小,导致需要频繁的扩容,不希望一次增加太多,造成空间上的浪费。

因此,在内存比较小的时候(<4MB)的时候,倍增64->128->256字节,这种方式大多数应用可以接收

当内存达到阀值时,再倍增就会带来额外的内存浪费,例如10MB->20MB,因此使用步增的方式进行扩张。

代码如下:

    @Override    public int calculateNewCapacity(int minNewCapacity, int maxCapacity) {        if (minNewCapacity < 0) {            throw new IllegalArgumentException("minNewCapacity: " + minNewCapacity + " (expectd: 0+)");        }        if (minNewCapacity > maxCapacity) {            throw new IllegalArgumentException(String.format(                    "minNewCapacity: %d (expected: not greater than maxCapacity(%d)",                    minNewCapacity, maxCapacity));        }        final int threshold = 1048576 * 4; // 4 MiB page        if (minNewCapacity == threshold) {            return threshold;        }        // If over threshold, do not double but just increase by threshold.        if (minNewCapacity > threshold) {            int newCapacity = minNewCapacity / threshold * threshold;            if (newCapacity > maxCapacity - threshold) {                newCapacity = maxCapacity;            } else {                newCapacity += threshold;            }            return newCapacity;        }        // Not over threshold. Double up to 4 MiB, starting from 64.        int newCapacity = 64;        while (newCapacity < minNewCapacity) {            newCapacity <<= 1;        }        return Math.min(newCapacity, maxCapacity);    }

计算完长度,再创建新的缓冲区,由于内存申请方式不同子类不同,依旧设置为一个抽象方法:

    public abstract ByteBuf capacity(int newCapacity);

4. 操作索引

与索引相关的操作主要是读写索引 mark reset等等。这部分代码相当简单。

5. 重用缓冲区

0->readerIndex这部分的空间可以重用。

    public ByteBuf discardReadBytes() {        ensureAccessible();        if (readerIndex == 0) {            return this;        }        if (readerIndex != writerIndex) {
 //1. 字节组进行复制 setBytes(
0, this, readerIndex, writerIndex - readerIndex);
       //2. 重新设置索引 writerIndex
-= readerIndex; adjustMarkers(readerIndex); readerIndex = 0; } else { adjustMarkers(readerIndex); writerIndex = readerIndex = 0; } return this; }

注意到还要重新调整markedReaderIndex和markedWriterIndex。

6. skipBytes

在解码的时候,有时候需要丢弃非法的数据报文。非常简单,修改readerIndex即可,

    @Override    public ByteBuf skipBytes(int length) {        checkReadableBytes(length);        readerIndex += length;        return this;    }

3.3 AbstractReferenceCountedByteBuf源码分析

从类的名字可以看出,该类的功能主要是引用计数,类似于JVM内存回收的对象引用计数器,用于跟踪对象的分配和销毁,用于自动的内存回收。

1. 成员变量

    private static final AtomicIntegerFieldUpdater<AbstractReferenceCountedByteBuf> refCntUpdater;    static {        AtomicIntegerFieldUpdater<AbstractReferenceCountedByteBuf> updater =                PlatformDependent.newAtomicIntegerFieldUpdater(AbstractReferenceCountedByteBuf.class, "refCnt");        if (updater == null) {            updater = AtomicIntegerFieldUpdater.newUpdater(AbstractReferenceCountedByteBuf.class, "refCnt");        }        refCntUpdater = updater;    }    private volatile int refCnt = 1;

refCntUpdater是一个CAS类型变量,通过原子操作对成员变量进行更新。

refCnt是一个volatile修饰的字段,用于跟踪对象的引用次数。

2. 对象引用计数器

CAS算法,每调用一次retain方法,引用计数器就会+1.

    @Override    public ByteBuf retain() {        for (;;) {            int refCnt = this.refCnt;            final int nextCnt = refCnt + 1;            // Ensure we not resurrect (which means the refCnt was 0) and also that we encountered an overflow.            if (nextCnt <= 1) {                throw new IllegalReferenceCountException(refCnt, 1);            }            if (refCntUpdater.compareAndSet(this, refCnt, nextCnt)) {                break;            }        }        return this;    }

下面看释放引用计数器的代码,也是使用CAS在一个自旋循环里进行判断和更新的。需要注意的是:当refCnt==1的时候意味着申请和释放相等,说明对象引用已经不可达,该对象需要被垃圾回收掉,因此调用deallocate方法来释放ByteBuf对象,代码如下:

    @Override    public boolean release() {        for (;;) {            int refCnt = this.refCnt;            if (refCnt == 0) {                throw new IllegalReferenceCountException(0, -1);            }            if (refCntUpdater.compareAndSet(this, refCnt, refCnt - 1)) {                if (refCnt == 1) {                    deallocate();                    return true;                }                return false;            }        }    }

3.4 UnpooledHeapByteBuf

基于堆内存,没有对象池,意味着每次I/O的读写都会创建一个新的UnpooledHeapByteBuf,频繁进行大块内存的分配和回收可能会对性能有一定的影响,但是相比于堆外内存的申请和释放,成本还是要低一些。

相比于PooledHeapByteBuf,其原理更加的简单,也不容易出现内存管理方面的问题,因此在满足性能的情况下,推荐使用UnpooledHeapByteBuf。

1. 成员变量

    
  //1. 用于内存分配
  private final ByteBufAllocator alloc;
  //2. 数组缓冲区
byte[] array;
//3.
private ByteBuffer tmpNioBuf;

2. 动态扩展缓冲区

    public ByteBuf capacity(int newCapacity) {        ensureAccessible();        if (newCapacity < 0 || newCapacity > maxCapacity()) {            throw new IllegalArgumentException("newCapacity: " + newCapacity);        }        int oldCapacity = array.length;
      //1. 如果新的容量值大于当前的缓冲区容量,需要动态扩展
if (newCapacity > oldCapacity) { byte[] newArray = new byte[newCapacity];
        //进行数组复制 System.arraycopy(array,
0, newArray, 0, array.length);
        // 替换旧的数组 setArray(newArray); }
else if (newCapacity < oldCapacity) {
       //此时,需要截取当前缓冲区创建一个新的子缓冲区
byte[] newArray = new byte[newCapacity]; int readerIndex = readerIndex();
        //如果读索引<新的容量值
if (readerIndex < newCapacity) { int writerIndex = writerIndex(); if (writerIndex > newCapacity) { writerIndex(writerIndex = newCapacity); }
        //拷贝内容 System.arraycopy(array, readerIndex, newArray, readerIndex, writerIndex
- readerIndex); } else {
          //如果此时读索引更大,无须拷贝数据 setIndex(newCapacity, newCapacity); } setArray(newArray); }
return this; }

3. 字节数组复制

    @Override    public ByteBuf setBytes(int index, byte[] src, int srcIndex, int length) {        checkSrcIndex(index, length, srcIndex, src.length);        System.arraycopy(src, srcIndex, array, index, length);        return this;    }

此时不会修改readerIndex和writerIndex,只是修改内容.

4. 转换为ByteBuf

    public ByteBuffer nioBuffer(int index, int length) {        ensureAccessible();        return ByteBuffer.wrap(array, index, length).slice();    }

5. 子类相关方法

isDirect: 由于是基于heap,所以返回false

hasArray: 返回true

array: 返回array

    @Override    public boolean hasArray() {        return true;    }    @Override    public byte[] array() {        ensureAccessible();        return array;    }    @Override    public int arrayOffset() {        return 0;    }    @Override    public boolean hasMemoryAddress() {        return false;    }    @Override    public long memoryAddress() {        throw new UnsupportedOperationException();    }

其它:

由于UnpooledDirectByteBuf原理和UnpooledHeapByteBuf相同,不同之处在于使用内部缓冲区DirectByteBuffer实现,这里不再描述。

        setByteBuffer(ByteBuffer.allocateDirect(initialCapacity));

3.5 PooledByteBuf内存池原理分析

细节非常复杂,这里仅仅从设计角度上讲解。

1. PoolArena

Arena本身是一块区域,在内存管理中,Memory Arena是指内存中的一大块连续的区域PoolArena就是Netty的内存池实现类。

为了集中管理内存的分配和释放,同时提高分配和释放内存时候的性能,很多框架和应用都会通过预先申请一大块内存,然后通过提供相应的分配和释放接口来使用内存。

这样,对内存的管理就会被集中到几个类或者函数中,由于不再频繁使用系统调用来申请和释放内存,应用或者系统的性能也会大大提高。这种设计思路中,预先申请的那一大块内存就会被称为Memeory Arena。

不同的框架中,Memory Arena的实现不同,Netty的PoolArena是由多个Chunk组成的大块内存区域,而每个Chunk则由一个或者多个Page组成。

代码片段如下:

abstract class PoolArena<T> implements PoolArenaMetric {    static final boolean HAS_UNSAFE = PlatformDependent.hasUnsafe();    enum SizeClass {        Tiny,        Small,        Normal    }    static final int numTinySubpagePools = 512 >>> 4;    final PooledByteBufAllocator parent;    private final int maxOrder;    final int pageSize;    final int pageShifts;    final int chunkSize;    final int subpageOverflowMask;    final int numSmallSubpagePools;    private final PoolSubpage<T>[] tinySubpagePools;    private final PoolSubpage<T>[] smallSubpagePools;    private final PoolChunkList<T> q050;    private final PoolChunkList<T> q025;    private final PoolChunkList<T> q000;    private final PoolChunkList<T> qInit;    private final PoolChunkList<T> q075;    private final PoolChunkList<T> q100;    private final List<PoolChunkListMetric> chunkListMetrics;

2. PoolChunk

Chunk中Page被构建为一棵二叉树。假设一个Chunk由16个Page组成,那么这些Page会被按照下图方式组织起来。

技术分享

Page的大小是4个byte,而Chunk的大小是64即4*16。树有5层,叶子节点所在层用来分配所有的Page内存,而上一层用来分配2个Page,以此类推...

每个节点都记录了自己在整个Memory Arena中的偏移地址,当一个节点代表的内存区域被分配出去之后,这个节点就被标记为已分配,自这个节点以下的所有节点在后面的内存请求都会被忽略。例如,需要16个byte的时候,就会在第三层寻找,然后标记已经分配,再分配只能寻找其他的三个节点了。

对树的遍历算法采用的是深度优先的算法,但是在选择哪个子节点继续遍历的时候是随机的。

3. PoolSubpage

对于小于一个Page的内存,Netty在Page中完成分配。每个Page会被切分为大小相同的多个存储块,存储块的大小由第一次申请内存的块大小决定。

假设一个Page是8个字节,第一次申请的块大小是4个字节,那么这个Page就包含了2个存储块;如果第一次申请的是8个字节,那么这个Page就被分成一个存储块。同时,之后能分配的也是和第一次一样的字节,如果不一样,需要在一个新的Page中进行分配。

Page中存储区域的使用状态通过一个long数组来维护,数组中每个long的每一位表示一个块存储区域的占用情况:0表示未占用,1表示已占用。对于个4bytes的Page来说,如果这个Page用来分配1个字节的存储区域,那么long数组只用一个元素的低4位就可以描述,如果对于一个128bytes的Page,如果也是1byte分配就有128个,就需要2个long元素来代表区域占用情况。

final class PoolSubpage<T> implements PoolSubpageMetric {    final PoolChunk<T> chunk;    private final int memoryMapIdx;    private final int runOffset;    private final int pageSize;    private final long[] bitmap;    PoolSubpage<T> prev;    PoolSubpage<T> next;    boolean doNotDestroy;    int elemSize;    private int maxNumElems;    private int bitmapLength;    private int nextAvail;    private int numAvail;

4. 内存回收策略

无论是Chunk还是Page,都使用状态位(bitmap)来标识内存是否可用,不同之处在于Chunk通过在二叉树上对节点进行标识Page则是通过维护块的状态标识来实现

3.6 PooledDirectByteBuf

基于内存池实现,基于直接缓冲,与UnPooledDirectByteBuf唯一的不同就是内存分配和销毁策略不同,其他都是相同的。

1. 创建字节缓冲区实例

通过静态工厂创建:

    static PooledDirectByteBuf newInstance(int maxCapacity) {        PooledDirectByteBuf buf = RECYCLER.get();        buf.reuse(maxCapacity);        return buf;    }

设置引用计数器为1,设置缓冲区最大容量后返回。

    /**     * Method must be called before reuse this {@link PooledByteBufAllocator}     */    final void reuse(int maxCapacity) {        maxCapacity(maxCapacity);        setRefCnt(1);        setIndex0(0, 0);        discardMarks();    }

2. 复制新的字节缓冲区实例

如果使用者确实需要复制一个新的实例,与原来的PooledDirectByteBuf独立,则调用它的copy(int index, int length) 可以达到上述目标,代码:

    @Override    public ByteBuf copy(int index, int length) {        checkIndex(index, length);        ByteBuf copy = alloc().directBuffer(length, maxCapacity());        copy.writeBytes(this, index, length);        return copy;    }

上述代码中,首先对index和length进行合法性校验,通过之后调用PooledByteBufAllocator分配一个新的ByteBuf,最终调用的是AbstractByteAllocator的directBuffer方法。

    @Override    public ByteBuf directBuffer(int initialCapacity, int maxCapacity) {        if (initialCapacity == 0 && maxCapacity == 0) {            return emptyBuf;        }        validate(initialCapacity, maxCapacity);        return newDirectBuffer(initialCapacity, maxCapacity);    }

newDirectBuffer方法根据子类实现不同策略,此处是Pooled,从池中获取而不是创建一个新的对象。

    @Override    protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) {        PoolThreadCache cache = threadCache.get();        PoolArena<ByteBuffer> directArena = cache.directArena;        ByteBuf buf;        if (directArena != null) {            buf = directArena.allocate(cache, initialCapacity, maxCapacity);        } else {            if (PlatformDependent.hasUnsafe()) {                buf = UnsafeByteBufUtil.newUnsafeDirectByteBuf(this, initialCapacity, maxCapacity);            } else {                buf = new UnpooledDirectByteBuf(this, initialCapacity, maxCapacity);            }        }        return toLeakAwareBuffer(buf);    }

3. 其它相关功能

    @Override    public boolean hasArray() {        return false;    }    @Override    public byte[] array() {        throw new UnsupportedOperationException("direct buffer");    }    @Override    public int arrayOffset() {        throw new UnsupportedOperationException("direct buffer");    }    @Override    public boolean hasMemoryAddress() {        return false;    }    @Override    public long memoryAddress() {        throw new UnsupportedOperationException();    }

四、ByteBuf相关辅助类介绍

4.1 ByteBufHolder

ByteBufHolder是ByteBuf相关的容器,在Netty中非常有用。

例如HTTP协议的请求消息和应答消息都可以携带消息体,这个消息体在NIO ByteBuffer中就是ByteBuffer对象,在Netty中就是ByteBuf对象。而不同的协议消息体中可以含有不同的协议字段和功能,因此需要对ByteBuf进行包装和抽象。

为了满足这些定制化的需求,Netty抽象出了ByteBufHolder对象,它包含了一个ByteBuf,另外还提供了一些其他实用的方法,使用者继承ByteBufHolder接口可以按需封装自己的实现。

下面是其类图,非常丰富。

技术分享

4.2 ByteBufAllocator

ByteBufAllocator是字节缓冲区分配器,按照Netty的缓冲区实现不同,共有2种不同的分配器,基于内存池的字节缓冲分配器和普通的字节缓冲区分配器。

技术分享

下图是主要API列表:

技术分享

4.3 CompositeByteBuf

CompositeByteBuf允许将多个ByteBuf的实例组装到一起,形成一个统一的视图。

某些场景下非常有用,例如某个协议POJO对象包含2部分:消息头和消息体,它们都是ByteBuf对象。当需要对消息进行编码的时候需要进行整合,如果使用JDK的话,有以下2种思路:

(1) 将某个ByteBuffer复制到另一个ByteBuffer中,或者创建一个新的ByteBuffer

(2) 通过List等容器,统一维护和处理

Netty的做法则是使用组合模式进行优化。

public class CompositeByteBuf extends AbstractReferenceCountedByteBuf implements Iterable<ByteBuf> {    private static final ByteBuffer EMPTY_NIO_BUFFER = Unpooled.EMPTY_BUFFER.nioBuffer();    private static final Iterator<ByteBuf> EMPTY_ITERATOR = Collections.<ByteBuf>emptyList().iterator();    private final ByteBufAllocator alloc;    private final boolean direct;    private final List<Component> components;    private final int maxNumComponents;    private boolean freed;

它定义了一个Component的集合,Component就是ByteBuf的包装类:

    private static final class Component {        final ByteBuf buf;        final int length;        int offset;        int endOffset;        Component(ByteBuf buf) {            this.buf = buf;            length = buf.readableBytes();        }        void freeIfNecessary() {            buf.release(); // We should not get a NPE here. If so, it must be a bug.        }    }

增加和删除的代码:

    public CompositeByteBuf addComponent(boolean increaseWriterIndex, ByteBuf buffer) {        checkNotNull(buffer, "buffer");        addComponent0(increaseWriterIndex, components.size(), buffer);        consolidateIfNeeded();        return this;    }
    /**     * Remove the {@link ByteBuf} from the given index.     *     * @param cIndex the index on from which the {@link ByteBuf} will be remove     */    public CompositeByteBuf removeComponent(int cIndex) {        checkComponentIndex(cIndex);        Component comp = components.remove(cIndex);        comp.freeIfNecessary();        if (comp.length > 0) {            // Only need to call updateComponentOffsets if the length was > 0            updateComponentOffsets(cIndex);        }        return this;    }

4.4 ByteBufUtil

工具类,提供静态方法用于操作ByteBuf对象。

技术分享

最有用的是对字符串进行编码和解码:

public static ByteBuf encodeString(ByteBufAllocator alloc, CharBuffer src, Charset charset): 对字符串进行编码,使用指定的ByteBufAllocator生成一个新的ByteBuf。

还有方法是hexDump,将ByteBuf内容以16进制的字符串打印出来。

Netty(7)源码-ByteBuf