可参考的地址：//www.greatytc.com/p/15304cd63175
ByteBuf：继承了Comparable和ReferenceCounted，前者可以比较ByteBuf对象内容的大小，后者是类似于引用计数器，无论是pool还是unpool 都采用了引用计数器，基于对象池的，当对象释放时候是放入recycle，内存放入poolArea。不基于对象池的对象释放的时候对象和内存直接等待gc（如果是堆外就是收动释放）。
ByeBuf是netty采用来替代ByeBuffer的，但是会在最终发送的时候还是把它ByeBuf转化成ByeBuffer。
原始的ByteBuffer的缺点：
1.只有一个标志位position来标识读写，每次切换需要flip对于开发来说不友好。
2.实际存储数据的数组采用final修饰不可以动态扩容，需要重新生成一个ByteBuffer对象
ByeBuf的优点：
1.使用readerIndex和writerIndex分别维护读操作和写操作，实现读写索引分离，更加直观。
2.ByteBuf使用的底层数据维护数组没有使用final关键字，所以存在直接在原来ByteBuf进行扩容的可能，而这件事，netty已经为我们完成，封装在它的write系列方法当中。但是它也存在着一个上限，这个上限就是Integer.MAX_VALUE.
API介绍
---readXXX 和writexxx都是属于顺序读写
1.提供了7种java类型的读写（即把他们转换成字节）和ByteBuf与ByteBuffer之间的转换(就是相当于new一个ByteBuffer对象，然后吧内部的字节数组在保障下，这样不会发生内存拷贝)
2.readXXX（xx是java的七个类型，）的api都是从readerIndex获取对应的java类型的值，readerIndex增长的大小就是我们获取的类型大小，比如int是4，doubble是8 byte，boolean 等是1 short是2
3.readBytes（int）创建新的bytebuf 和新的读写索引以及底层复制数组
4.readSlices（int）创建新的bytebuf 共享一个数据内存，维护独立的读写锁
5.readBytes（ByteBuf）,将数据读取到目标ByteBuf
6.writexxx，都是将各种类型的数据写入到bytebuf，writeZero是写入NUL到byteBuf
7.discardBytes:不能频繁使用 因为他是需要内存拷贝的
8.skipBytes是指跳过一些字节
10.clear：重置读写索引为0，这样我们可以覆盖之前写的数据
11.mark 和reset 分别可以记录读写锁 然后重置，我们一般可以比如像重复读取一块内容可以这么写
12.查找操作 indexof，byteBefore 都是查找满足的字节
13.duplicate 是复制一个bytebuf 共享内存，但是维护独立的读写索引，修改内存会影响另一个bytebuf的数据
14.copy是维护独立的内存和索引
15.slice 类似于duplicate 但是至少获取部分内存
16.转换成bytebuffer 都是共享内部的数组，但是转换后如果原始的bytebuf在动态扩展 后来的bytebuffer是感觉不到的，因为原先的bytebuf是得到一个新的数组
---setXXX 和getxxx都是属于随机读写
1.set和get都是指定位置进行读写，但是set操作不支持动态扩展，必须确保长度够使用
ByteBuf 有堆内外和pool以及unpool区分
堆内存：优点是内存分配和回收速度快，可以自动被jvm回收。缺点就是消息发送的时候需要吧jvm的内存数据复制到内核的socket上面
堆外内存：不需要上面的复制，但是分配和回收内存比较慢，且需要手动回收
----我们目前都是在后端业务开发的时候使用堆内存，然后io线程通信的时候使用堆外内存
pool：通过对ByteBuf对象和堆外内存，堆外内存进行池化，降低当数据量变大，导致频繁创建对象，从而导致gc
unpool：易操作，易懂
注意点：
1、我们bytebuf的缓冲区的实现（实际承载数据）--对于heap采用的是字节数组 对于direct采用的是java的bytebuffer
2.对于我们派生derived，比如调用slice方法，我们在release的时候也需要调用其父类的release
3.最好使用ByteBufAllocator生产bytebuf，而不要直接new
4.对于pool RECYCLER 存放的是Bytebuf，PoolArena 存放的是字节数组或者ByteBuffer，同时pool的时候还会在每个线程上持有一个threadCache（其实是fastthreadlocal对象）通过他保存PoolThreadCache，PoolThreadCache内部的PoolArena内部可以分配一个完整的对象包含内存。
5.我们写操作时候每次都会看数据量是否超过目前的内存大小，如果超过但是没有超过最大值，则进行扩展，扩展是按照先倍增然后在步进，因为初始时候内存大小较小
源码分析：//www.greatytc.com/p/742f39d4967d
目前主要是针对pool情况下堆内外bytebuf的创建和release进行分析，以及ByteBuffer如何释放堆外内存。同时包含对于下面四个组件的分析
PoolThreadCache：
绑定在nioevnetloop线程上面 可以通过他获取poolArena，从而进行pool对象的分配
recycle：我们在分配内存之前必须先获取对应的bytebuf，作为承载内存的对象容器
poolArena：里面有一系列根据我们分配内存大小的逻辑进行分配
CompositeByteBuf:将各种不同的bytebuf组装成一个视图，避免了无畏的
unsafe：创建内存对象的时候（数组或者ByteBuffer），如果有unsafe 我们可以借助unsafe进行更快的操作内存对象
这边的有没有unsafe 我觉得是有没有权限使用unsafe，对于jdk肯定有
但是对于netty不一定有
没有unsafe，直接采用jdk原生的directByteBuffer
UnpooledDirectByteBuf
UnpooledUnsafeNoCleanerDirectByteBuf
UnpooledUnsafeDirectByteBuf
上述三个都是netty自己的对象，区别在创建directbytebuffer方式和一个成员变量 memoryAddress
UnpooledDirectByteBuf：就是常规的调用directbytebuffer创建对象，然后回收依靠虚引用的特性，最终调用cleaner内部持有的一个线程，该线程依靠unsafe进行回收内存
UnpooledUnsafeNoCleanerDirectByteBuf和UnpooledUnsafeDirectByteBuf都比上面多了一个memoryAddress，这样我们操作对象，可以更快。区别就是欠揍因为没法使用cleaner，所以通过反射调用directbytebuffer没有创建cleaner的构造函数，释放的时候也通过反射调用unsafe的回收内存方法。
当然上面这几个底层还是采用unsafe分配和回收内存
unsafe的好处：我们知道我们java访问对象的方式有两种 一种是使用句柄池，一种是直接使用对象地址
前者的好处是当对象移动的时候 我们不需要修改对象引用中的指针，只需要调整句柄池和对象地址之间的指针
后者的好处就是速度快，省却了一次指针定位时间
我们java采用前者，但是通过unsafe可以绕过指针定位的时间
