PooledByteBuf
PooledByteBuf是池化的ByteBuf，提高了内存分配与释放的速度，它本身是一个抽象泛型类，
有三个子类:PooledDirectByteBuf、PooledHeapByteBuf、PooledUnsafeDirectByteBuf.
Jemalloc算法
Netty的PooledByteBuf采用与jemalloc一致的内存分配算法。基本思路可用这样的情景类比，想象一下电商的配送流程。当顾客采购小件商品(比如书籍)时，直接从同城仓库送出；当顾客采购大件商品(比如电视)时，从区域仓库送出；当顾客采购超大件商品(比如汽车)时，则从全国仓库送出。Netty的分配算法与此相似。Netty中，Tiny和Small类型的请求都首先从同城仓库(ThreadCache-tcache)送出;如果同城仓库没有，则会从区域。仓库(PoolArena)送出，Normal类型的请求则从区域仓库(PoolArena)送出，Huge类型的请求则从全国仓库(系统内存)送出。
Netty中规定:
- 1.内存分配的最小单位为16B
- 2.小于512B的请求为Tiny，512B<x<8KB(PageSize)的请求为Small,8KB<=X<=16MB(ChunkSize)的请求为Normal,大于16MB(ChunkSize)的请求为Huge
- 3.Tiny、Small、Normal、Huge中还有细层级，小于Tiny的请求以16B为起点每次增加16B作为一个层级，也就是
Tiny中还有16B、32B、48B、…480B、496B的层级
其他类型的则是翻倍:
Small中还有512B、1KB、2KB、4KB的层级
Normal中还有8KB、16KB、32KB…8MB、16MB的层级
Huge中还有32MB、64MB…的层级 - 4.不管请求的大小，都会将向上规范化，比如:请求分配511B、512B、513B，将依次规范化为512B、512B、1KB
为了提高内存分配效率并减少内部碎片，jemalloc算法将Arena切分为小块Chunk,根据每块的内存使用率又将小块组合为以下集中状态QINIT,Q0,Q25,Q50,Q75,Q100。Chunk块可以在这几种状态间随着内存使用率的变化进行转移，内存使用率和状态转移如图所示。
其中横轴表示内存使用率(百分比),纵轴表示状态，可以看到:
QINIT的内存使用率为[0,25),Q0为(0,50),Q100为[100,100]等等。
Chunk的初始状态为QINIT,当使用率达到25时转移到Q0状态，再次达到50时转移到Q25,依次类推直到Q100；当内存释放时又从Q100转移到Q75,直到Q0状态且内存使用率为0时，该Chunk从Arena中删除。像qinit、q000、q075因为本身要维护很多Chunk块，所以内部是以链表的形式来组织Chunk块，同时qinit、q000、q075本身又组织为一个近似的双向链表，如图所示。
虽然已将Arena切分成小块的Chunk,但实际上Chunk是相当大的内存块，在Netty中默认使用16MB。为了进一步提高内存利用率，并减少内部碎片，需要继续将Chunk切分为小的快Page.一个典型的切换将Chunk切分为2048块，可知Page的大小为:16MB/2048=8KB.一个好的内存分配算法，应使得已分配内存块尽可能保持连续，这将大大减少内部碎片，由此jemalloc使用伙伴分配算法尽可能提高连续性。伙伴分配算法的基本思想是:
我们知道一个Chunk切分为2048块Page,将这些Page作为叶子节点，然后组织起一个满二叉树，然后按层分配满足要求的内存块。以待分配序列8KB、16KB、8KB为例分析分配过程(每个Page大小8KB)： - 8KB–需要一个Page,第11层满足要求，故分配2048节点即Page0
- 16KB-需要两个Page，故需要在第10层进行分配，而1024节点的子节点2048已分配，从左到右找到满足要求的1025节点，故分配节点1025即Page2和Page3
- 8KB–需要一个Page，第11层满足要求，2048已分配，从左到右找到2049节点即Page1进行分配。分配结束后，已分配连续的Page0-Page3,这样的连续内存块，大大减少内部碎片并提高内存使用率，为了实现伙伴算法，Netty中使用了memoryMap和depthMap来表示两棵二叉树，其中MemoryMap存放分配信息，depthMap存放节点的高度信息
我们在前面说过，一个page是8KB，但是Netty又支持Tiny、Small这种小于8KB,最小可达16B的内存分配请求，每次都分配一个page,很浪费。为了进一步切分Page成更小的SubPage，SubPage是jemalloc中内存分配的最小单位，不能再进行切分.SubPage切分的单位并不固定，以第一次请求分配的大小为单位(最小切分单位为16B).比如，第一次请求分配32B,则Page按照32B均等切分为256块；第一次请求请求16B，则Page按照16B均等切分512块。为了便于内存分配和管理，根据SubPage的切分单位进行分组，对每个组而言，Arena会以双向链表的形式进行管理。那么根据切分的单位的大小和Page的大小，SubPage分为两类:tinySubPagePools和smallSubPagePools，tinySubPage中的subPage的大小，从16字节到496个字节，共有32个元素，smallSubPagePools则有512字节、1024、2048、4096共4个元素。如图所示。
在Arena数量上，为了减少各个线程进行内存分配时竞争，Netty中会有多个Arena，默认的数量与处理器的个数有关，线程首次分配内存时，首先会为其分配一个固定的Arena
左图表示每个节点的编号，注意从1开始，省略0是因为这样更容易计算父子关系:子节点加倍，父节点减半，比如512的子节点为1024=512 *2.右图表示每个节点的深度，注意从0开始。在代表二叉树的数组中，左图中节点上的数字作为数组索引即id,右图节点上的数字作为值。初始
状态时，memoryMap和depthMap相等，可知一个id为512节点的初始值为9，memoryMap[512]=depthMap[512]=9，depthMap的值初始化后不再改变，memoryMap的值随着节点分配而改变，当一个节点被分配以后，
该节点的值设置为12(最大高度+1)表示不可用，并且会更新祖先节点的值。
分配过程如下:
4号节点被完全分配，将高度值设置为12表示不可用。
4号节点的父亲节点即2号节点，将高度值更新为两个子节点的较小值；其他祖先节点亦然，直到高度值更新到根节点，可推知，memoryMap数组的值有如下三种情况:
- memoryMap[id]=depthMap[id] – 该节点没有被分配
- memoryMap[id] > depthMap[id] – 至少有一个子节点被分配，不能再分配该高度满足的内存，但可以根据实际分配较小一些的内存，比如，上图中分配了4号子节点的2号节点，值从1更新为2，表示该节点不能再分配8MB的只能最大分配4MB内存，因为分配了4号节点后只剩下5号节点可用。
- memoryMap[id] = 最大高度 +1 (本例中12) – 该节点及其子节点已被完全分配，没有剩余空间。
PoolThreadCache.
同时在Netty中为了提升性能，并不会一开始就从PoolArena中分配，因为Arena为几个线程共享，而是先从每个线程自己的PoolThreadCache中去获取。当然开始的是偶，这些Cache里面都是没有值的，要先从PoolArena中获取，当释放Buf的时候,才会把之前分配的内存大小放到该cache里面，当下次申请内存的时候，就会先从PoolThreadCache中找。
PoolThreadCache中则维护了6个这样的线程缓存区域，3个堆内存相关，3个直接内存相关，分别对应着三种
分配内存的大小small类型的数组的大小为4，而tiny、normal数组的大小分别为32、3，smallSubPageHeapCache的数组长度为4，依次缓存[512K,1024K,2048K,4096K]大小的缓存，每个元素对应的缓存
queue中的元素个数不能超过256个，而tinySubPageHeapCaches数组缓存的是[16B,32B,…,496B]大小的内存块，每个元素，对应的缓存queue中元素个数不能超过512个，normalHeapCaches数组结构相同，但是只缓存[8K，16K,32K]大小的内存块,每个元素对应的缓存queue中元素个数不超过64个。每一个MemoryRegionCache中又包含一个队列。队列中的每个元素类型为Entry,Entry中又包含了一个PoolChunk，以方便对内存的管理
