前面分別分析了PoolChunk、PoolSubpage和PoolChunkList，本文主要分析PoolArena。
1、深入淺出Netty內存管理 PoolChunk
2、深入淺出Netty內存管理 PoolSubpage
3、深入淺出Netty內存管理 PoolChunkList
PoolArena
應用層的內存分配主要通過如下實現，但最終還是委托給PoolArena實現。
PooledByteBufAllocator.DEFAULT.directBuffer(128);
由于netty通常應用于高并發系統，不可避免的有多線程進行同時內存分配，可能會極大的影響內存分配的效率，為了緩解線程競爭，可以通過創建多個poolArena細化鎖的粒度，提高并發執行的效率。
先看看poolArena的內部結構：
所有內存分配的size都會經過normalizeCapacity進行處理，當size>=512時，size成倍增長512->1024->2048->4096->8192，而size<512則是從16開始，每次加16字節。
poolArena提供了兩種方式進行內存分配：
- PoolSubpage用于分配小于8k的內存；
- tinySubpagePools：用于分配小于512字節的內存，默認長度為32，因為內存分配最小為16，每次增加16，直到512，區間[16，512)一共有32個不同值；
- smallSubpagePools：用于分配大于等于512字節的內存，默認長度為4；
- tinySubpagePools和smallSubpagePools中的元素都是默認subpage。
- poolChunkList用于分配大于8k的內存；
- qInit：存儲內存利用率0-25%的chunk
- q000：存儲內存利用率1-50%的chunk
- q025：存儲內存利用率25-75%的chunk
- q050：存儲內存利用率50-100%的chunk
- q075：存儲內存利用率75-100%的chunk
- q100：存儲內存利用率100%的chunk
- qInit前置節點為自己，且minUsage=Integer.MIN_VALUE，意味著一個初分配的chunk，在最開始的內存分配過程中(內存使用率<25%)，即使完全釋放也不會被回收，會始終保留在內存中。
- q000沒有前置節點，當一個chunk進入到q000列表，如果其內存被完全釋放，則不再保留在內存中，其分配的內存被完全回收。
接下去看看poolArena如何實現內存的分配，實現如下：
private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
final int normCapacity = normalizeCapacity(reqCapacity);
if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
int tableIdx;
PoolSubpage<T>[] table;
boolean tiny = isTiny(normCapacity);
if (tiny) { // < 512
if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
// was able to allocate out of the cache so move on
return;
}
tableIdx = tinyIdx(normCapacity);
table = tinySubpagePools;
} else {
if (cache.allocateSmall(this, buf, reqCapacity, normCapacity)) {
// was able to allocate out of the cache so move on
return;
}
tableIdx = smallIdx(normCapacity);
table = smallSubpagePools;
}
final PoolSubpage<T> head = table[tableIdx];
/**
* Synchronize on the head. This is needed as {@link PoolChunk#allocateSubpage(int)} and
* {@link PoolChunk#free(long)} may modify the doubly linked list as well.
*/
synchronized (head) {
final PoolSubpage<T> s = head.next;
if (s != head) {
assert s.doNotDestroy && s.elemSize == normCapacity;
long handle = s.allocate();
assert handle >= 0;
s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
if (tiny) {
allocationsTiny.increment();
} else {
allocationsSmall.increment();
}
return;
}
}
allocateNormal(buf, reqCapacity, normCapacity);
return;
}
if (normCapacity <= chunkSize) {
if (cache.allocateNormal(this, buf, reqCapacity, normCapacity)) {
// was able to allocate out of the cache so move on
return;
}
allocateNormal(buf, reqCapacity, normCapacity);
} else {
// Huge allocations are never served via the cache so just call allocateHuge
allocateHuge(buf, reqCapacity);
}
}
1、默認先嘗試從poolThreadCache中分配內存，PoolThreadCache利用ThreadLocal的特性，消除了多線程競爭，提高內存分配效率；首次分配時，poolThreadCache中并沒有可用內存進行分配，當上一次分配的內存使用完并釋放時，會將其加入到poolThreadCache中，提供該線程下次申請時使用。
2、如果是分配小內存，則嘗試從tinySubpagePools或smallSubpagePools中分配內存，如果沒有合適subpage，則采用方法allocateNormal分配內存。
3、如果分配一個page以上的內存，直接采用方法allocateNormal分配內存。
allocateNormal實現如下：
private synchronized void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
++allocationsNormal;
if (q050.allocate(buf, reqCapacity, normCapacity)
|| q025.allocate(buf, reqCapacity, normCapacity)
|| q000.allocate(buf, reqCapacity, normCapacity)
|| qInit.allocate(buf, reqCapacity, normCapacity)
|| q075.allocate(buf, reqCapacity, normCapacity)
|| q100.allocate(buf, reqCapacity, normCapacity)) {
return;
}
// Add a new chunk.
PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);
long handle = c.allocate(normCapacity);
assert handle > 0;
c.initBuf(buf, handle, reqCapacity);
qInit.add(c);
}
第一次進行內存分配時，chunkList沒有chunk可以分配內存，需通過方法newChunk新建一個chunk進行內存分配，并添加到qInit列表中。如果分配如512字節的小內存，除了創建chunk，還有創建subpage，PoolSubpage在初始化之后，會添加到smallSubpagePools中，其實并不是直接插入到數組，而是添加到head的next節點。下次再有分配512字節的需求時，直接從smallSubpagePools獲取對應的subpage進行分配。
分配內存時，為什么不從內存使用率較低的q000開始？在chunkList中，我們知道一個chunk隨著內存的釋放，會往當前chunklist的前一個節點移動。
q000存在的目的是什么？
q000是用來保存內存利用率在1%-50%的chunk，那么這里為什么不包括0%的chunk？
直接弄清楚這些，才好理解為什么不從q000開始分配。q000中的chunk，當內存利用率為0時，就從鏈表中刪除，直接釋放物理內存，避免越來越多的chunk導致內存被占滿。
想象一個場景，當應用在實際運行過程中，碰到訪問高峰，這時需要分配的內存是平時的好幾倍，當然也需要創建好幾倍的chunk，如果先從q0000開始，這些在高峰期創建的chunk被回收的概率會大大降低，延緩了內存的回收進度，造成內存使用的浪費。
那么為什么選擇從q050開始？
1、q050保存的是內存利用率50%~100%的chunk，這應該是個折中的選擇！這樣大部分情況下，chunk的利用率都會保持在一個較高水平，提高整個應用的內存利用率；
2、qinit的chunk利用率低，但不會被回收；
3、q075和q100由于內存利用率太高，導致內存分配的成功率大大降低，因此放到最后；
END。
我是占小狼。
在魔都艱苦奮斗，白天是上班族，晚上是知識服務工作者。
如果讀完覺得有收獲的話，記得關注和點贊哦。
非要打賞的話，我也是不會拒絕的。
