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内部有这么几个属性
- minNewCapacity：表用户需要写入的目标值大小
- threshold：阈值，为Bytebuf内部设定容量的最大值，默认4M
- maxCapacity：Netty最大能接受的容量大小，一般为int的最大值
扩容方法
1..如果目标值等于阈值，使用阀值作为实际容量值
2.如果目标值大于阈值，用每次步进4MB的方式进行内存扩张（(需要扩容值/4MB)X4MB）, 如果超过maxCapacity直接使用maxCapacity作为实际容量值
3.如果目标值小于阀值，采用倍增的方式，以64（字节）作为基本数值，每次翻倍增长64 -->128 --> 256，直到倍增后的结果大于或等于需要的容量值，倍增的结果作为实际容量值
评论区