Netty内存池原理分析

为了避免频繁的内存分配给系统带来负担以及GC对系统性能带来波动，Netty4提出了全新的内存管理，使用了全新的内存池来管理内存的分配和回收。内存池这块的代码复杂难懂，而且几乎没有注释阅读起来比较费力，特别是以前没有接触过内存分配算法的阅读起来更为蛋疼，好在经过几个晚上的努力，终于捋出了一些端倪，特来此记录一番。

Netty4的内存池集大家之精华，参考了各路英雄豪杰的优秀思想，它参考了slab分配，Buddy（伙伴）分配。接触过memcached的应该了解slab分配，它的思路是把内存分割成大小不等的内存块，用户线程请求内存时根据请求的内存大小分配最贴近size的内存块，在减少内存碎片的同时又能很好的避免内存浪费。Buddy分配是在分配的过程中把一些内存块等量分割，回收时合并，尽可能保证系统中有足够大的连续内存。

Netty内存分配包括了堆内存和非堆内存（Direct内存），但是内存分配的核心算法是类似，所以从堆内存分配代码入手来学习整个内存池的原理。

PoolArena

在应用层通过设置PooledByteBufAllocator来执行ByteBuf的分配，但是最终的内存分配工作被委托给PoolArena，由于Netty通常用于高并发系统，所以各个线程进行内存分配时竞争不可避免，这可能会极大的影响内存分配的效率，为了缓解高并发时的线程竞争，Netty允许使用者创建多个分配器（Arena）来细化锁的粒度，从而达到分离竞争点的目的，当然是以内存来作为代价的。可以通过PooledByteBufAllocator构造子中的nHeapArena参数来执行Arena的数量，或者通过key为io.netty.allocator.numHeapArenas的系统变量进行设置，它有一个默认值，通过一下代码决定默认值：

[java]  view plain  copy

 

1. DEFAULT_NUM_HEAP_ARENA = Math.max(0,  
2.                 SystemPropertyUtil.getInt(  
3.                         "io.netty.allocator.numHeapArenas",  
4.                         (int) Math.min(  
5.                                 runtime.availableProcessors(),  
6.                                 Runtime.getRuntime().maxMemory() / defaultChunkSize / 2 / 3)));  

根据CPU核心数以及默认内存块（chunk）大小等参数来计算这个默认值。Arena通过R-R轮叫的方式为各个线程服务，看PoolThreadCache的get方法中的代码片段：

[java]  view plain  copy

 

1. final int idx = index.getAndIncrement();  
2. final PoolArena<byte[]> heapArena;  
3. final PoolArena<ByteBuffer> directArena;  
4.   
5. if (heapArenas != null) {  
6.     heapArena = heapArenas[Math.abs(idx % heapArenas.length)];  
7. } else {  
8.     heapArena = null;  
9. }  

内存单元

内存池中包含页（page）和块（chunk）两种分配单位，页大小可以通过PooledByteBufAllocator构造子中的pageSize传入，或者通过系统变量io.netty.allocator.pageSize设置，默认8192即8K，这个pageSize大小不是随意设置是有限制的，它必须大于4096（4K），而且为了方便的支持位运算使内存分配更高效，它必须是2的整数次幂。对于chunkSize它是通过pageSize和maxOrder参数计算而来，计算公式是chunkSize=pageSize*（2的maxOrder次幂），maxOrder可以通过PooledByteBufAllocator构造子的maxOrder参数或io.netty.allocator.maxOrder系统变量设置，只能设置0-14范围内的值，默认值11，也就是说一个chunk大小默认等于2的11次方个page，chunkSize的计算方法可以查看PooledByteBufAllocator的validateAndCalculateChunkSize方法代码：

[java]  view plain  copy

 

1. private static int validateAndCalculateChunkSize(int pageSize, int maxOrder) {  
2.     if (maxOrder > 14) {  
3.         throw new IllegalArgumentException("maxOrder: " + maxOrder + " (expected: 0-14)");  
4.     }  
5.   
6.     // Ensure the resulting chunkSize does not overflow.  
7.     int chunkSize = pageSize;  
8.     for (int i = maxOrder; i > 0; i --) {  
9.         if (chunkSize > MAX_CHUNK_SIZE / 2) {  
10.             throw new IllegalArgumentException(String.format(  
11.                     "pageSize (%d) << maxOrder (%d) must not exceed %d", pageSize, maxOrder, MAX_CHUNK_SIZE));  
12.         }  
13.         chunkSize <<= 1;  
14.     }  
15.     return chunkSize;  
16. }  

在Arena中通过tinySubpagePools和smallSubpagePools来缓存分配给tiny（小于512）和small（大等于512）的内存页。同时创建了6个Chunk列表（PoolChunkList）来分配给Normal（超过一页）大小，包括：

• qInit：存储剩余内存0-25%的chunk
• q000：存储剩余内存1-50%的chunk
• q025：存储剩余内存25-75%的chunk
• q050：存储剩余内存50-100%个chunk
• q075：存储剩余内存75-100%个chunk
• q100：存储剩余内存100%chunk

这六个PoolChunkList也通过链表串联，串联关系是：qInit->q000->q025->q050->q075->q100。

分配区

内存池包含两层分配区：线程私有分配区和内存池公有分配区。当内存被分配给某个线程之后，在释放内存时释放的内存不会直接返回给公有分配区，而是直接在线程私有分配区中缓存，当线程频繁的申请内存时会提高分配效率，同时当线程申请内存的动作不活跃时可能会造成内存浪费的情况，这时候内存池会对线程私有分配区中的情况进行监控，当发现线程的分配活动并不活跃时会把线程缓存的内存块释放返回给公有区。在整个内存分配时可能会出现分配的内存过大导致内存池无法分配的情况，这时候就需要JVM堆直接分配，所以严格的讲有三层分配区。

内存分配

下面是内存分配大致流程图：

计算分配内存量

内存池采用了slab分配思路，内存被划分成固定大小的内存单元，所以会根据使用者请求的内存进行计算，匹配最接近的内存单元。在计算时分下面几种情况：

请求的内存大小是否超过了chunkSize，如果已超出说明一个该内存已经超出了一个chunk能分配的范围，直接返回原始大小。

请求大小大于等于512，返回一个512的2次幂倍数当做最终的内存大小，当原始大小是512时，返回512，当原始大小在(512，1024]区间，返回1024，当在(1024，2048]区间，返回2048等等。

请求大小小于512，返回一个16的整数倍，原始大小(0，16]区间返回16，(16，32]区间返回32，(32，48]区间返回48等等，这些大小的内存块在内存池中叫tiny块。

相关代码在PoolArena的normalizeCapacity方法：

[java]  view plain  copy

 

1. int normalizeCapacity(int reqCapacity) {  
2.         if (reqCapacity < 0) {  
3.             throw new IllegalArgumentException("capacity: " + reqCapacity + " (expected: 0+)");  
4.         }  
5.         if (reqCapacity >= chunkSize) {  
6.             return reqCapacity;  
7.         }  
8.   
9.         if (!isTiny(reqCapacity)) { // >= 512  
10.             // Doubled  
11.   
12.             int normalizedCapacity = reqCapacity;  
13.             normalizedCapacity --;  
14.             normalizedCapacity |= normalizedCapacity >>>  1;  
15.             normalizedCapacity |= normalizedCapacity >>>  2;  
16.             normalizedCapacity |= normalizedCapacity >>>  4;  
17.             normalizedCapacity |= normalizedCapacity >>>  8;  
18.             normalizedCapacity |= normalizedCapacity >>> 16;  
19.             normalizedCapacity ++;  
20.   
21.             if (normalizedCapacity < 0) {  
22.                 normalizedCapacity >>>= 1;  
23.             }  
24.   
25.             return normalizedCapacity;  
26.         }  
27.   
28.         // Quantum-spaced  
29.         if ((reqCapacity & 15) == 0) {  
30.             return reqCapacity;  
31.         }  
32.   
33.         return (reqCapacity & ~15) + 16;  
34.     }  

分配的内存大小小于512时内存池分配tiny块，大小在[512，pageSize]区间时分配small块，tiny块和small块基于page分配，分配的大小在(pageSize，chunkSize]区间时分配normal块，normall块基于chunk分配，内存大小超过chunk，内存池无法分配这种大内存，直接由JVM堆分配，内存池也不会缓存这种内存。

线程私有分配

为了避免线程竞争，内存分配优先在线程内分配，在PoolThreadCache中定义了tinySubPageHeapCaches、smallSubPageHeapCaches、normalHeapCaches分别在线程内缓存tiny、small、normall内存块，其中tiny块的个数为32个，small块的个数有pageSize来决定，它的计算公式是：pageShifts - 9，这个pageShifts就是pageSize二进制表示时尾部0的个数，那么按照这种方式有没有可能因为0的数量小于9个而导致计算结果是负数呢？当然不会，上面提到了pageSize不是随意设置的，它必须大于4096（4K），pageSize是4096时，它的二进制表示是1000000000000，那么这个pageShifts就是12，所以small块的数量就是3。pageShifts的计算代码在PooledByteBufAllocator的validateAndCalculatePageShifts方法中：

[java]  view plain  copy

 

1. private static int validateAndCalculatePageShifts(int pageSize) {  
2.     if (pageSize < MIN_PAGE_SIZE) {  
3.         throw new IllegalArgumentException("pageSize: " + pageSize + " (expected: " + MIN_PAGE_SIZE + "+)");  
4.     }  
5.   
6.     if ((pageSize & pageSize - 1) != 0) {  
7.         throw new IllegalArgumentException("pageSize: " + pageSize + " (expected: power of 2)");  
8.     }  
9.   
10.     // Logarithm base 2. At this point we know that pageSize is a power of two.  
11.     return Integer.SIZE - 1 - Integer.numberOfLeadingZeros(pageSize);  
12. }  

normal块的个数计算稍微复杂一点，它和三个参数有关：chunkSize、pageSize、maxCachedBufferCapacity，chunkSize和pageSize前面已经介绍过了，maxCachedBufferCapacity这个参数使用者可以通过设置io.netty.allocator.maxCachedBufferCapacity系统变量传入，默认是32 * 1024。取chunkSize和maxCachedBufferCapacity中最小的一个和pageSize做个除法，这就是normal块的个数。在前面提到过了，chunkSize=pageSize*（2的maxOrder次幂），maxOrder的默认值是11，pageSize默认值8192，所以默认情况下，normal块的数量应该是32 * 1024/8192=4。

在分配时通过请求的内存大小计算内存块的索引，对于tiny计算方式如下：

[java]  view plain  copy

 

1. static int tinyIdx(int normCapacity) {  
2.     return normCapacity >>> 4;  
3. }  

在上面提到了tiny块的大小只能是16的倍数，所以通过上面代码计算出来的索引就是0,1,2,3,4........31。

对于small计算方式如下：

[java]  view plain  copy

 

1. static int smallIdx(int normCapacity) {  
2.     int tableIdx = 0;  
3.     int i = normCapacity >>> 10;  
4.     while (i != 0) {  
5.         i >>>= 1;  
6.         tableIdx ++;  
7.     }  
8.     return tableIdx;  
9. }  

因为small块的大小是512的2次幂倍数，代码函数中计算512计算出0，1024计算出1，2048计算出2，4096计算出3等等。

normal计算方式如下：

[java]  view plain  copy

 

1. int idx = log2(normCapacity >> numShiftsNormalHeap);  

numShiftsNormalHeap是pageSize的对数，pageSize为8192时，numShiftsNormalHeap的值是13，normal块的size都是大于pageSize的，所以它的值也是512的2次幂倍数，当normCapacity小于等于8192时计算出的idx是0,8192*2时为1，8192*4时为2。

计算出索引之后就可以定位到线程中的内存块（MemoryRegionCache）了，MemoryRegionCache维护了一个Entry列表，每个Entry都对应一个可分配的内存单元Chunk以及一个长整形数handle，内存分配成功之后会给应用层返回这个chunk和handle，这个handle的作用后面再介绍。

全局分配

内存池的初始阶段，线程是没有内存缓存的，所以最开始的内存分配都需要在全局分配区进行分配，全局分配区的内存构造和线程私有分配区的类似，也包含了tiny、small、normal几种规模，计算索引的方式也都是一模一样的，代码都完全复用。
无论是tinySubpagePools还是smallSubpagePools成员，在内存池初始化时是不会预置内存的，所以最开始的内存分配都会进入PoolArena的allocateNormal方法：

[java]  view plain  copy

 

1. private synchronized void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {  
2.     if (q050.allocate(buf, reqCapacity, normCapacity) || q025.allocate(buf, reqCapacity, normCapacity) ||  
3.         q000.allocate(buf, reqCapacity, normCapacity) || qInit.allocate(buf, reqCapacity, normCapacity) ||  
4.         q075.allocate(buf, reqCapacity, normCapacity) || q100.allocate(buf, reqCapacity, normCapacity)) {  
5.         return;  
6.     }  
7.   
8.     // Add a new chunk.  
9.     PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);  
10.     long handle = c.allocate(normCapacity);  
11.     assert handle > 0;  
12.     c.initBuf(buf, handle, reqCapacity);  
13.     qInit.add(c);  
14. }  

初始状态下所有的PoolChunkList都是空的，所以在此先创建chunk块并且添加到PoolChunkList中，需要注意的是虽然都是通过qInit.add添加chunk，这并不代表chunk都会被添加到qInit这个PoolChunkList，看一下PoolChunkList的add方法就可以知道：

[java]  view plain  copy

 

1. void add(PoolChunk<T> chunk) {  
2.     if (chunk.usage() >= maxUsage) {  
3.         nextList.add(chunk);  
4.         return;  
5.     }  
6.   
7.     chunk.parent = this;  
8.     if (head == null) {  
9.         head = chunk;  
10.         chunk.prev = null;  
11.         chunk.next = null;  
12.     } else {  
13.         chunk.prev = null;  
14.         chunk.next = head;  
15.         head.prev = chunk;  
16.         head = chunk;  
17.     }  
18. }  

PoolChunkList有两个重要的参数minUsage和maxUsage，这两个参数都是使用率，当chunk中内存可用率在[minUsage,maxUsage]区间时，这个chunk才会落到该PoolChunkList中，否则把chunk传到下一个PoolChunkList进行检查，从这里可以看出，chunk只会被添加到内存匹配的PoolChunkList中，为了更有说服力，再看一下free方法的代码：

[java]  view plain  copy

 

1. void free(PoolChunk<T> chunk, long handle) {  
2.     chunk.free(handle);  
3.     if (chunk.usage() < minUsage) {  
4.         remove(chunk);  
5.         if (prevList == null) {  
6.             assert chunk.usage() == 0;  
7.             arena.destroyChunk(chunk);  
8.         } else {  
9.             prevList.add(chunk);  
10.         }  
11.     }  
12. }  

在释放内存时会检查minUsage，如果不匹配传到上一个PoolChunkList进行检查。
在上面的allocateNormal方法代码看到，创建了chunk之后调用了PoolChunk.allocate进行真正的分配动作，在分析这个分配动作之前先来了解一下这个PoolChunk，它有几个重要的参数：

1、memory，物理内存，内存请求者千辛万苦拐弯抹角就是为了得到它，在HeapArena中它就是一个chunkSize大小的byte数组。

2、memoryMap数组，内存分配控制信息，数组元素是一个32位的整数数，该整形数包含如下信息：

• 1-2位：状态，包含四种状态：未分配（ST_UNUSED，0）、被拆分（ST_BRANCH，1）、已分配（ST_ALLOCATED，2）、分配了子页（ST_ALLOCATED_SUBPAGE，3）。
• 3-17位：size，内存占用的page个数。
• 18-32位：offset，在chunk中的偏移量。

这个数组的大小等于pageSize*2，但是实际上只会使用pageSize*2-1个位置，第一个位置（索引为0的位置）未被使用，在PoolChunk初始化时填充该数组，每个元素代表一种分配方式，当chunkSize=8*pageSize时，该数组初始化完成之后它的第一个元素size域等于8，offset等于0表示一次性分配8页，第三个元素size等于4，offset等于4，表示一次性分配4页，从第五页开始分配。memoryMap初始化之后在结构上可以看做是一颗完美二叉树（所有非叶子结点都有且只有两个字结点，所有叶子结点的高度相同），对于8页的chunk它类似于下图（s=size，o=offset）：

这个过程可以理解不断的分裂内存块的过程。memoryMap初始化代码在PoolChunk的构造方法中：

[java]  view plain  copy

 

1. int chunkSizeInPages = chunkSize >>> pageShifts;  
2. maxSubpageAllocs = 1 << maxOrder;  
3.   
4. // Generate the memory map.  
5. memoryMap = new int[maxSubpageAllocs << 1];  
6. int memoryMapIndex = 1;  
7. for (int i = 0; i <= maxOrder; i ++) {  
8.     int runSizeInPages = chunkSizeInPages >>> i;  
9.     for (int j = 0; j < chunkSizeInPages; j += runSizeInPages) {  
10.         //noinspection PointlessBitwiseExpression  
11.         memoryMap[memoryMapIndex ++] = j << 17 | runSizeInPages << 2 | ST_UNUSED;  
12.     }  
13. }  

所有的状态初始化时都是ST_UNUSED。
3、subpages数组，页分配信息，数组元素的个数等于chunk中page的数量。

在进行内存分配时，memoryMap的第一元素（索引1的元素）开始检查，通过上面的分析可以知道第一个元素的size是等于chunkSize的，当然memoryMap中只存储了页数量，通过runLength方法把页数转换成内存大小：

[java]  view plain  copy

 

1. private int runLength(int val) {  
2.     return (val >>> 2 & 0x7FFF) << pageShifts;  
3. }  

对于大于pageSize的内存，分配过程如下：

内存块是否已被分配，如果已被分配，返回-1标识分配失败。

请求的内存是否和当前memoryMap数组元素表示的内存相等，如果相等直接返回该数组元素的索引，并且把状态置成ST_ALLOCATED已分配。如果不相等，把当前元素状态设置成已分裂ST_BRANCH，跳到它其中的一个子节点，并把另外一个子节点的状态设置成ST_UNUSED。

内存块是否已被分裂，如果已分裂，跳到它的子节点，检查子节点是否可以成功分配，否则跳到子节点的兄弟节点（即当前节点的另一个子节点）。

相关代码：

[java]  view plain  copy

 

1. private long allocateRun(int normCapacity, int curIdx, int val) {  
2.     for (;;) {  
3.         if ((val & ST_ALLOCATED) != 0) { // state == ST_ALLOCATED || state == ST_ALLOCATED_SUBPAGE  
4.             return -1;  
5.         }  
6.   
7.         if ((val & ST_BRANCH) != 0) { // state == ST_BRANCH  
8.             int nextIdx = curIdx << 1 ^ nextRandom();  
9.             long res = allocateRun(normCapacity, nextIdx, memoryMap[nextIdx]);  
10.             if (res > 0) {  
11.                 return res;  
12.             }  
13.   
14.             curIdx = nextIdx ^ 1;  
15.             val = memoryMap[curIdx];  
16.             continue;  
17.         }  
18.   
19.         // state == ST_UNUSED  
20.         return allocateRunSimple(normCapacity, curIdx, val);  
21.     }  
22. }  
23.   
24. private long allocateRunSimple(int normCapacity, int curIdx, int val) {  
25.     int runLength = runLength(val);  
26.     if (normCapacity > runLength) {  
27.         return -1;  
28.     }  
29.   
30.     for (;;) {  
31.         if (normCapacity == runLength) {  
32.             // Found the run that fits.  
33.             // Note that capacity has been normalized already, so we don't need to deal with  
34.             // the values that are not power of 2.  
35.             memoryMap[curIdx] = val & ~3 | ST_ALLOCATED;  
36.             freeBytes -= runLength;  
37.             return curIdx;  
38.         }  
39.   
40.         int nextIdx = curIdx << 1 ^ nextRandom();  
41.         int unusedIdx = nextIdx ^ 1;  
42.   
43.         memoryMap[curIdx] = val & ~3 | ST_BRANCH;  
44.         //noinspection PointlessBitwiseExpression  
45.         memoryMap[unusedIdx] = memoryMap[unusedIdx] & ~3 | ST_UNUSED;  
46.   
47.         runLength >>>= 1;  
48.         curIdx = nextIdx;  
49.         val = memoryMap[curIdx];  
50.     }  
51. }  

分配成功之后，PoolChunk会返回一个正32位整形数，这个数就是memoryMap数组的索引，接下来根据这些信息初始化PooledByteBuf：

[java]  view plain  copy

 

1. void initBuf(PooledByteBuf<T> buf, long handle, int reqCapacity) {  
2.     int memoryMapIdx = (int) handle;  
3.     int bitmapIdx = (int) (handle >>> 32);  
4.     if (bitmapIdx == 0) {  
5.         int val = memoryMap[memoryMapIdx];  
6.         assert (val & 3) == ST_ALLOCATED : String.valueOf(val & 3);  
7.         buf.init(this, handle, runOffset(val), reqCapacity, runLength(val));  
8.     } else {  
9.         initBufWithSubpage(buf, handle, bitmapIdx, reqCapacity);  
10.     }  
11. }  

根据索引获取到memoryMap数组中的元素，根据该元素可以提取出offset和size，最终通过offset和size初始化ByteBuf：

[java]  view plain  copy

 

1. void init(PoolChunk<T> chunk, long handle, int offset, int length, int maxLength) {  
2.     assert handle >= 0;  
3.     assert chunk != null;  
4.   
5.     this.chunk = chunk;  
6.     this.handle = handle;  
7.     memory = chunk.memory;  
8.     this.offset = offset;  
9.     this.length = length;  
10.     this.maxLength = maxLength;  
11.     setIndex(0, 0);  
12.     tmpNioBuf = null;  
13. }  

调用完这个方法之后，就说明chunk中从偏移量offset开始总长度为length的内存被我这个ByteBuf占用了。

[java]  view plain  copy

 

1. protected final int idx(int index) {  
2.     return offset + index;  
3. }  
4. @Override  
5. protected byte _getByte(int index) {  
6.     return memory[idx(index)];  
7. }  

到这对大于pageSize的内存分配就结束了。当chunk被填充到PoolChunkList之后，在后续的内存分配中有可能会直接在PoolChunkList中分配，遍历PoolChunkList所有的chunk直到分配成功为止，具体分配逻辑是一样的，这里不再赘述，在分配成功之后因为chunk的使用率会发生变化，所以PoolChunkList中的chunk会有所调整，把分配内存后的chunk调整到适合它的PoolChunkList中。

对于大小在pageSize以内的内存分配，由PoolSubpage类来辅助分配，在PoolArena中定义了tinySubpagePools和smallSubpagePools分别存储tiny页和small页，数组元素都是一个PoolSubpage链表的头指针，挂接多个大小相同的page。同样通过normCapacity来计算数组索引，同样是通过tinyIdx和smallIdx方法进行计算。page的分配是按需的，假如一个page是8K，一次只请求了1K，那么剩下的7K会继续分配给其它的请求，PoolSubpage中有几个重要属性：

• elemSize，每次分配的内存大小。
• maxNumElems，内存页最多能被分配多少次，也即一页可划分成多少大小相同的内存单元，maxNumElems=pageSize/elemSize。
• numAvail，内存页还能分配多少次，它的初始值等同于maxNumElems，分配一次值递减。
• nextAvail，内存页内的下一个待分配块的索引，在上面分析Normal分配的时候了解到了，当内存分配成功之后会返回一个handle整形数，通过这个整数型来计算偏移量来确定最终的物理内存，而页内分配除了返回handle整数计算在chunk内的偏移量，同时还需要返回一个bitmapIdx来计算页内的偏移量，通过这两个偏移量来确定最终的物理内存，这个bitmapIdx的值等同于nextAvail。
• bitmap，位图数组，每个元素是一个长整形数数，记录内存页的分配信息，每个二进制位都代表页内的一个内存单元，当二进制位为1表示对应的内存块被分配过，第一个元素对应0-63号内存单元，第二个元素对应64-127号内存单元等等，bitmap[0]=0b0000000...0001111表示0,1,2,3这四个内存单元都已经被分配给对应的请求了。这个bitmap用来辅助计算下一个分配块的索引也即上面的nextAvail参数。

内存池初始化时内存页缓存tinySubpagePools和smallSubpagePools页都是空的，在PoolSubpage初始化之后会自动把它添加到tinySubpagePools或smallSubpagePools中的一个缓存中，见PoolSubpage的init方法：

[java]  view plain  copy

 

1. void init(int elemSize) {  
2.     doNotDestroy = true;  
3.     this.elemSize = elemSize;  
4.     if (elemSize != 0) {  
5.         maxNumElems = numAvail = pageSize / elemSize;  
6.         nextAvail = 0;  
7.         bitmapLength = maxNumElems >>> 6;  
8.         if ((maxNumElems & 63) != 0) {  
9.             bitmapLength ++;  
10.         }  
11.   
12.         for (int i = 0; i < bitmapLength; i ++) {  
13.             bitmap[i] = 0;  
14.         }  
15.     }  
16.   
17.     addToPool();  
18. }  

在分配page内存时先要定位到对应的PoolSubpage，如果还未创建过和当前请求大小匹配的PoolSubpage先创建然后添加到缓存中，下次分配时可直接从缓存中读取。

page的分配时同样从memoryMap的第一元素（索引1的元素）开始检查，检查过程如下：

状态是ST_BRANCH，跳到到它的一个直接子节点重复分配过程。

状态是ST_UNUSED，重复跳到节点的任意一个子节点动作，并且把经过的节点的状态都置成ST_BRANCH，直到到达叶子节点为止（据前面的分析，叶子节点都对应一个page），把最后达到的叶子节点状态置成ST_ALLOCATED_SUBPAGE，初始化PoolSubpage并且在PoolSubpage上进行内存分配返回一个长整形数，该长整形数的1-32位存储memoryMapIdx，33-62存储bitmapIdx。

状态是ST_ALLOCATED_SUBPAGE，定位到对应的PoolSubpage，并且在该PoolSubpage上进行内存分配，这个PoolSubpage之前分配过内存给某个请求，所以这次分配在nextAvail索引上继续分配，当PoolSubpage所有的内存单元都被分配完，那么把它从缓存中删除，见代码：

[java]  view plain  copy

 

1. long allocate() {  
2.     if (elemSize == 0) {  
3.         return toHandle(0);  
4.     }  
5.   
6.     if (numAvail == 0 || !doNotDestroy) {  
7.         return -1;  
8.     }  
9.   
10.     final int bitmapIdx = nextAvail;  
11.     int q = bitmapIdx >>> 6;  
12.     int r = bitmapIdx & 63;  
13.     assert (bitmap[q] >>> r & 1) == 0;  
14.     bitmap[q] |= 1L << r;  
15.   
16.     if (-- numAvail == 0) {  
17.         removeFromPool();  
18.         nextAvail = -1;  
19.     } else {  
20.         nextAvail = findNextAvailable();  
21.     }  
22.   
23.     return toHandle(bitmapIdx);  
24. }  

内存释放

前面已经提到了，内存池不会预置内存块到线程缓存中，在线程申请到内存使用完成之后归还内存时优先把内存块缓存到线程中，除非该内存块不适合缓存在线程中（内存太大），当当前线程内存分配动作非常活跃时，这样会明显的提高分配效率，但是当它不活跃时对内存又是极大的浪费，所以内存池会监控该线程，随时做好把内存从线程缓存中删除的准备，详见MemoryRegionCache类的trim方法代码：

[java]  view plain  copy

 

1. private void trim() {  
2.     int free = size() - maxEntriesInUse;  
3.     entriesInUse = 0;  
4.     maxEntriesInUse = 0;  
5.   
6.     if (free <= maxUnusedCached) {  
7.         return;  
8.     }  
9.   
10.     int i = head;  
11.     for (; free > 0; free--) {  
12.         if (!freeEntry(entries[i])) {  
13.             // all freed  
14.             return;  
15.         }  
16.         i = nextIdx(i);  
17.     }  
18. }  

maxUnusedCached值等于缓存中Entry数量的一半，当缓存中空闲的内存块数量超过总Entry数的一半时说明线程的内存分配动作不活跃，释放所有Entry对应的chunk，当内存分配的次数超过阀值freeSweepAllocationThreshold时就会进行一次活跃度检查并释放不活跃线程缓存中空闲的内存。这里可能会存在问题：回收动作是有allocate触发的，加入某一个线程在从内存池中请求到内存之后在也没有触发过内存分配并且线程一直吃存活的，那么缓存到该线程中的内存可能就无法回收了，这种情况不太可能出现在Netty多路复用器中的线程，因为多路复用器中的线程会处理IO事件，处理IO事件时ByteBuf都会向内存池请求内存，但是如果线程是使用者自定义的线程，那这个问题是有可能存在的。

除此之后内存池中还有一个任务用来监控线程状态，当发现线程不是存活态时回收被其缓存的内存。详见内部类ReleaseCacheTask：

[java]  view plain  copy

 

1. private final class ReleaseCacheTask implements Runnable {  
2.     private ScheduledFuture<?> releaseTaskFuture;  
3.   
4.     @Override  
5.     public void run() {  
6.         synchronized (caches) {  
7.             for (Iterator<Map.Entry<Thread, PoolThreadCache>> i = caches.entrySet().iterator();  
8.                  i.hasNext();) {  
9.                 Map.Entry<Thread, PoolThreadCache> cache = i.next();  
10.                 if (cache.getKey().isAlive()) {  
11.                     // Thread is still alive...  
12.                     continue;  
13.                 }  
14.                 cache.getValue().free();  
15.                 i.remove();  
16.             }  
17.             if (caches.isEmpty()) {  
18.                 // Nothing in the caches anymore so no need to continue to check if something needs to be  
19.                 // released periodically. The task will be rescheduled if there is any need later.  
20.                 if (releaseTaskFuture != null) {  
21.                     releaseTaskFuture.cancel(true);  
22.                     releaseTaskFuture = null;  
23.                 }  
24.             }  
25.         }  
26.     }  
27. }  

无论内存块是从线程缓存还是从应用层归还到内存池，其基本步骤是一致的：

1、释放Chunk，在从内存池中分配内存时，内存池会返回一个handle的整形数给应用层，应用层需要保存这个handle并且在进行内存释放时把它传回，根据handle定位memoryMap中的分配状态信息，并且根据状态做不同的处理：

• 状态是页分配ST_ALLOCATED_SUBPAGE，根据handle定位出对应的PoolSubpage，设置bitmap数组对应的位，把1还原为0。
• 状态不是页分配，还原状态，设置成ST_UNUSED，如果兄弟节点的状态也是ST_UNUSED，那么当前回收的节点可以和兄弟节点合并，把它们的父节点的状态也设置成ST_UNUSED，使得后面进行内存分配时有更大的内存块可以选择，父节点依次递归。

2、调整Chunk所在的PoolChunkList，内存回收之后Chunk中的可用内存会发生变化，可能已经不在当前PoolChunkList的范围中了，需要往前调整。