ByteBuffer
ByteBuffer是一个抽象类，NIO编程中经常会使用，Netty常用的ByteBuf实际上也是对其的一种封装
-
Byte即字节，一个8位的二进制 -
Buffer即缓冲区，所谓缓冲区，其实就是一个临时存储数据的容器(可以理解为一个数组)，而且一般可以重用
缓冲区
缓冲区有什么用呐?
- 减少实际的物理读写次数
- 缓冲区创建时分配固定内存，这块内存区域可被重用，减少动态分配和回收内存的次数
举个简单的例子 比如我们去取快递(数据)，快递很多，一次只能取一个，那我们就需要来回跑很多趟(实际读写次数)
加入我们有个大筐，一次把快递全装回来，就省了不少事
这个大筐在这个过程就扮演一个“缓冲区”的作用，下次取快递还能用
byte[]
Buffer类是JDK1.4引入的NIO包中定义的一个抽象类，那我们先看看1.4之前一般是如何从管道获取数据的，大概写法如下:
byte[] bytes = new byte[1024];
int read = clientSocket.getInputStream().read(bytes);
System.out.println("received data：" + new String(bytes, 0, read));
我们接收IO流字节数据的方式是用一个byte[]来保存，这个byte[]其实已经起到一个缓冲区的作用，就是用起来不太方便，也不好重复利用
而NIO出版的ByteBuffer可以理解为对byte[]的一个封装，使其更易用于临时数据缓冲场景
ByteBuffer继承自Buffer类，Buffer类就是对缓冲区的一种抽象，让我们看看作为一个Buffer有哪些特性
Buffer
Buffer是一个线性的、有界、方便重用的容器
属性
它有4个重点属性，capacity，limit，position，mark，我不先介绍其含义，从实际使用角度阐述为什么需要这4个属性
首先作为一个有界容器，那肯定是要明确标识界限的，这样可以知道容器到底有多大，需要开辟多少空间，所以需要有个capacity代表容器的容量
作为一个线性容器，使用者希望写方法只要告诉容器写的是什么即可，而不用像数组一样需要指定index，取方法也一样，取完某一个再次取就接着取下一个，不需要指定index，所以就需要有个属性来标识当前读/写的位置，即position，每次读/写结束，直接把position向后移动一位，下一次读/写就是下一个元素
Buffer支持读取操作时需要知道总共有多少可读，这个值并非capacity，因为容器可能未满，同时写操作，由于Buffer可重复利用，每次的最大可写量也并不一定是capacity，这两种需求都需要有个读写界限值，用limit标识
有时候我们需要从某个位置读完数据可能过一会又想从之前哪个位置重新读取一次，但关键我们的Buffer是线性的，position只能增不能减，如何找到之前的位置？所以buffer提供了一个mark属性让使用者可以标识之前的一个位置，并提供mark()方法让mark值等于position，读/写一段时间postion值变大了，可以调用reset()方法，让postion回到mark的值，这就可以重新从mark点位读取了
方法
上文已介绍两个针对mark属性的方法：mark() 和 rest()，除此之外还有几个方便的方法：
clear() :清空的意思，清空后就可以再次利用，所以说buffer很方便重用，clear方法把limit=capacity，position=0，mark=-1(置空)，为了重新写入做好准备(实际上并没有清空元素)
flip():字面意思翻转，实际实现是limit=position，position=0，为读取做好准备，一般是一个Buffer写完数据后转换为读模式时使用，所以名字叫翻转还是很贴切，翻转时limit=position记录了当前写到的最大位置，也是可读的最大位置，而position=0从头开始读
rewind:倒带，主要为了重新读，实现是position=0
HeapByteBuffer
讲完Buffer再次回到抽象类ByteBuffer，顾名思义，就是一个存字节的Buffer，他的一个重要属性:hb
就是被ByteBuffer封装的byte数组，而后面的注释说只有heap buffers使用这个属性，实现代表就是HeapByteBuffer，Heap代表了这种Buffer的实际存储地址是在堆内存中，就是hb属性指向的堆内存空间
那还有什么存储方式呐，就要介绍ByteBuffer的另一个实现DirectByteBuffer
DirectByteBuffer
DirectByteBuffer作为ByteBuffer自然是一个临时存储Byte的容器，但它的数据不存储在堆里，那么还能怎么存？存磁盘吗？
存磁盘显然是不可能，那慢死了，实际上DirectByteBuffer内的字节还是要存储在物理内存中，只不过并不属于java虚拟机运行时数据区的一部分，而是直接内存，也叫堆外内存
上图中HeapByteBuffer也是我们最常用的方式指向对中内存byte[]的地址，当读取IO数据时先把数据拷贝到直接内存，再拷贝到jvm内存中，两次拷贝
而DirectByteBuffer直接指向直接内存，省去了一步拷贝工作，这种技术也叫零拷贝，读取数据更快
对比
那问题就来了，既然直接内存IO速度都很快，为啥我们常用的确实HeapByteBuffer？
相比于堆内存，直接内存的分配时间较长，因为JVM内存是物理内存提前分配好的，属于虚拟机自己的内存分配肯定很快，而堆外内存需要重新向物理内存索要额外空间，肯定需要更长时间
还有一个重要原因：堆外内存不受GC管控，容易造成内存溢出(可以调用system.gc手动GC)
ByteBuf
netty中封装了一个ByteBuf，就使用到了DirectByteBuffer来创建直接内存，实现零拷贝，那么上面介绍了使用直接内存的缺点netty是如何攻破的呐
内存池设计
针对直接内存分配时间长的问题，netty使用内存池设计，为了尽量重用缓冲区减少分配时间，Netty提供了基于ByteBuf内存池的缓冲区重用机制。需要的时候直接从池子里获取ByteBuf使用即可，使用完毕之后就重新放回到池子里去
至于堆外内存不收GC管控问题，毕竟只是一个代码难写的问题，只要考虑到了手动回收即可
当然除零拷贝之外，ByteBuf还做了一些改进，使这个字节缓冲区更适用于网络IO场景
读写索引分离
相比如Buffer设计的position同时标志读写位置这种用起来很蹩脚的方式，ByteBuf提供了两个索引：readerIndex 和 writerIndex
通过readerindex和writerIndex和capacity，将buffer分成三个区域
- 已经读取的区域：[0,readerindex)
- 可读取的区域：[readerindex,writerIndex)
- 可写的区域: [writerIndex,capacity)
动态扩容
使用ByteBuf时会初始化一个容量，写入时，如果剩余容量不足以存放待存数据，会触发动态扩容
由于ByteBuf使用的是直接内存，每次都需要向操作系统申请一块更大的内存，消耗较大(虽然有池化技术，但频繁扩容依然很浪费)，所以ByteBuf动态扩容时，并不是缺多少补多少，而是按一定策略进行扩容(通俗点说就是要的时候尽量多给点，省着老要)，以下是ByteBuf动态扩容策略依据的几个重要的参数：
- minNewCapacity：为能保证本次写入，所需的最小容量，即扩容大于这个容量，才能装下待写入数据
- threshold：Bytebuf内部设定一个分水岭，容量在这个阈值之下和之上使用扩容策略不同，固定4m
- maxCapacity：Netty最大能接受的容量大小，也就是可扩容的上限，默认为int的最大值
所以ByteBuf的扩容策略主要分为两种，当minNewCapacity<threshold和minNewCapacity>threshold时使用的扩容策略不同
1.如果minNewCapacity<threshold，翻倍扩容，以64（字节）作为基本数值，循环翻倍计算：64 -->128 --> 256，直到计算的结果大于或等于需要的容量值，则以这个结果作为实际扩充后的新容量
2.如果minNewCapacity>threshold，用每次步进4MB的方式进行内存扩张（每次 +4MB 步进）, 如果超过maxCapacity直接使用maxCapacity作为实际容量值
3.如果minNewCapacity==threshold，直接扩容到threshold(这种比较极端)
ByteBuf之所以使用threshold分水岭来区分扩容策略，主要考虑的是：
- 容量基数小时快速增长，避免频繁扩容(因为基数小，翻倍也翻不了太多)
- 容量基数大的时候如果继续翻倍，一次申请的容量就会很大，很大概率造成浪费，所以每次固定容量步进增长
而threshold=4m就是 Netty 官方结合网络通讯场景精算出来的最优分界点。
