深入淺出Netty記憶體管理：PoolArena

阿新 • • 發佈：2019-01-14

前面分別分析了PoolChunk、PoolSubpage和PoolChunkList，本文主要分析PoolArena。

PoolArena

應用層的記憶體分配主要通過如下實現，但最終還是委託給PoolArena實現。

PooledByteBufAllocator.DEFAULT.directBuffer(128);

1	PooledByteBufAllocator.DEFAULT.directBuffer(128);

由於netty通常應用於高併發系統，不可避免的有多執行緒進行同時記憶體分配，可能會極大的影響記憶體分配的效率，為了緩解執行緒競爭，可以通過建立多個poolArena細化鎖的粒度，提高併發執行的效率。

先看看poolArena的內部結構：

poolArena

所有記憶體分配的size都會經過normalizeCapacity進行處理，當size>=512時，size成倍增長512->1024->2048->4096->8192，而size

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

poolChunkList

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);
    }
}

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758

privatevoidallocate(PoolThreadCache cache,PooledByteBuf<T>buf,finalintreqCapacity){finalintnormCapacity=normalizeCapacity(reqCapacity);if(isTinyOrSmall(normCapacity)){// capacity < pageSizeinttableIdx;PoolSubpage<T>[]table;booleantiny=isTiny(normCapacity);if(tiny){// < 512if(cache.allocateTiny(this,buf,reqCapacity,normCapacity)){// was able to allocate out of the cache so move onreturn;}tableIdx=tinyIdx(normCapacity);table=tinySubpagePools;}else{if(cache.allocateSmall(this,buf,reqCapacity,normCapacity)){// was able to allocate out of the cache so move onreturn;}tableIdx=smallIdx(normCapacity);table=smallSubpagePools;}finalPoolSubpage<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){finalPoolSubpage<T>s=head.next;if(s!=head){asserts.doNotDestroy&&s.elemSize==normCapacity;longhandle=s.allocate();asserthandle>=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 onreturn;}allocateNormal(buf,reqCapacity,normCapacity);}else{// Huge allocations are never served via the cache so just call allocateHugeallocateHuge(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);
}

123456789101112131415161718

privatesynchronized voidallocateNormal(PooledByteBuf<T>buf,intreqCapacity,intnormCapacity){++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);longhandle=c.allocate(normCapacity);asserthandle>0;c.initBuf(buf,handle,reqCapacity);qInit.add(c);}

第一次進行記憶體分配時，chunkList沒有chunk可以分配記憶體，需通過方法newChunk新建一個chunk進行記憶體分配，並新增到qInit列表中。如果分配如512位元組的小記憶體，除了建立chunk，還有建立subpage，PoolSubpage在初始化之後，會新增到smallSubpagePools中，其實並不是直接插入到陣列，而是新增到head的next節點。下次再有分配512位元組的需求時，直接從smallSubpagePools獲取對應的subpage進行分配。

smallSubpagePools

分配記憶體時，為什麼不從記憶體使用率較低的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由於記憶體利用率太高，導致記憶體分配的成功率大大降低，因此放到最後；

深入淺出Netty記憶體管理：PoolArena

PoolArena

q000存在的目的是什麼？

深入淺出Netty記憶體管理：PoolArena

深入淺出Netty記憶體管理：PoolSubpage

深入淺出Netty記憶體管理：PoolChunk

深入淺出Netty記憶體管理：PoolChunkList

資料庫記憶體管理：tcmalloc與jemalloc

Sqlserver記憶體管理：限制最大佔用記憶體

Spark靜態記憶體管理：StaticMemoryManager

iOS效能優化之記憶體管理：Analyze、Leaks、Allocations的使用和案例程式碼

Linux記憶體管理：HighMemory

iOS記憶體管理：記憶體洩露除錯的常用技巧

JVM記憶體管理：記憶體區域和記憶體洩漏

Linux記憶體管理：CMA

C語言動態記憶體管理：malloc、realloc、calloc以及free函式

作業系統的學習（2）——實體記憶體管理：連續記憶體分配

7.netty記憶體管理-ByteBuf

談談Netty記憶體管理

第四節：FreeRTOS 記憶體管理

QEMU深入淺出: guest實體記憶體管理

現代作業系統：第三章記憶體管理

深入淺出 Java 中 JVM 記憶體管理

深入淺出Netty記憶體管理：PoolArena

PoolArena

q000存在的目的是什麼？

相關推薦