原文：http://blog.csdn.net/rabbit729/archive/2009/02/23/3927979.aspx
看到一篇關于內存池技術的介紹文章，受益匪淺，轉貼至此。

  原貼地址：http://www.ibm.com/developerworks/cn/linux/l-cn-ppp/index6.html

 6.1 自定義內存池性能優化的原理

  如前所述，讀者已經了解到"堆"和"棧"的區別。而在編程實踐中，不可避免地要大量用到堆上的內存。例如在程序中維護一個鏈表的數據結構時，每次新增或者刪除一個鏈表的節點，都需要從內存堆上分配或者釋放一定的內存；在維護一個動態數組時，如果動態數組的大小不能滿足程序需要時，也要在內存堆上分配新的內存空間。

6.1.1 默認內存管理函數的不足

利用默認的內存管理函數new/delete或malloc/free在堆上分配和釋放內存會有一些額外的開銷。

系統在接收到分配一定大小內存的請求時，首先查找內部維護的內存空閑塊表，并且需要根據一定的算法（例如分配最先找到的不小于申請大小的內存塊給請求者，或者分配最適于申請大小的內存塊，或者分配最大空閑的內存塊等）找到合適大小的空閑內存塊。如果該空閑內存塊過大，還需要切割成已分配的部分和較小的空閑塊。然后系統更新內存空閑塊表，完成一次內存分配。類似地，在釋放內存時，系統把釋放的內存塊重新加入到空閑內存塊表中。如果有可能的話，可以把相鄰的空閑塊合并成較大的空閑塊。

默認的內存管理函數還考慮到多線程的應用，需要在每次分配和釋放內存時加鎖，同樣增加了開銷。

可見，如果應用程序頻繁地在堆上分配和釋放內存，則會導致性能的損失。并且會使系統中出現大量的內存碎片，降低內存的利用率。

默認的分配和釋放內存算法自然也考慮了性能，然而這些內存管理算法的通用版本為了應付更復雜、更廣泛的情況，需要做更多的額外工作。而對于某一個具體的應用程序來說，適合自身特定的內存分配釋放模式的自定義內存池則可以獲得更好的性能。

6.1.2 內存池的定義和分類

自定義內存池的思想通過這個"池"字表露無疑，應用程序可以通過系統的內存分配調用預先一次性申請適當大小的內存作為一個內存池，之后應用程序自己對內存的分配和釋放則可以通過這個內存池來完成。只有當內存池大小需要動態擴展時，才需要再調用系統的內存分配函數，其他時間對內存的一切操作都在應用程序的掌控之中。

應用程序自定義的內存池根據不同的適用場景又有不同的類型。

從線程安全的角度來分，內存池可以分為單線程內存池和多線程內存池。單線程內存池整個生命周期只被一個線程使用，因而不需要考慮互斥訪問的問題；多線程內存池有可能被多個線程共享，因此則需要在每次分配和釋放內存時加鎖。相對而言，單線程內存池性能更高，而多線程內存池適用范圍更廣。

從內存池可分配內存單元大小來分，可以分為固定內存池和可變內存池。所謂固定內存池是指應用程序每次從內存池中分配出來的內存單元大小事先已經確定，是固定不變的；而可變內存池則每次分配的內存單元大小可以按需變化，應用范圍更廣，而性能比固定內存池要低。

6.1.3 內存池工作原理示例

下面以固定內存池為例說明內存池的工作原理，如圖6-1所示。

圖6-1 固定內存池

  固定內存池由一系列固定大小的內存塊組成，每一個內存塊又包含了固定數量和大小的內存單元。

如圖6-1所示，該內存池一共包含4個內存塊。在內存池初次生成時，只向系統申請了一個內存塊，返回的指針作為整個內存池的頭指針。之后隨著應用程序對內存的不斷需求，內存池判斷需要動態擴大時，才再次向系統申請新的內存塊，并把所有這些內存塊通過指針鏈接起來。對于操作系統來說，它已經為該應用程序分配了4個等大小的內存塊。由于是大小固定的，所以分配的速度比較快；而對于應用程序來說，其內存池開辟了一定大小，內存池內部卻還有剩余的空間。

例如放大來看第4個內存塊，其中包含一部分內存池塊頭信息和3個大小相等的內存池單元。單元1和單元3是空閑的，單元2已經分配。當應用程序需要通過該內存池分配一個單元大小的內存時，只需要簡單遍歷所有的內存池塊頭信息，快速定位到還有空閑單元的那個內存池塊。然后根據該塊的塊頭信息直接定位到第1個空閑的單元地址，把這個地址返回，并且標記下一個空閑單元即可；當應用程序釋放某一個內存池單元時，直接在對應的內存池塊頭信息中標記該內存單元為空閑單元即可。

可見與系統管理內存相比，內存池的操作非常迅速，它在性能優化方面的優點主要如下。

（1）針對特殊情況，例如需要頻繁分配釋放固定大小的內存對象時，不需要復雜的分配算法和多線程保護。也不需要維護內存空閑表的額外開銷，從而獲得較高的性能。

（2）由于開辟一定數量的連續內存空間作為內存池塊，因而一定程度上提高了程序局部性，提升了程序性能。

（3）比較容易控制頁邊界對齊和內存字節對齊，沒有內存碎片的問題。

6.2 一個內存池的實現實例

本節分析在某個大型應用程序實際應用到的一個內存池實現，并詳細講解其使用方法與工作原理。這是一個應用于單線程環境且分配單元大小固定的內存池，一般用來為執行時會動態頻繁地創建且可能會被多次創建的類對象或者結構體分配內存。

本節首先講解該內存池的數據結構聲明及圖示，接著描述其原理及行為特征。然后逐一講解實現細節，最后介紹如何在實際程序中應用此內存池，并與使用普通內存函數申請內存的程序性能作比較。

6.2.1 內部構造

內存池類MemoryPool的聲明如下：

class MemoryPool
{
private:
    MemoryBlock*   pBlock;
    USHORT          nUnitSize;
    USHORT          nInitSize;
    USHORT          nGrowSize;

public:
                     MemoryPool( USHORT nUnitSize,
                                  USHORT nInitSize = 1024,
                                  USHORT nGrowSize = 256 );
                    ~MemoryPool();

    void*           Alloc();
    void            Free( void* p );
};
 

MemoryBlock為內存池中附著在真正用來為內存請求分配內存的內存塊頭部的結構體，它描述了與之聯系的內存塊的使用信息：

struct MemoryBlock
{
    USHORT          nSize;
    USHORT          nFree;
    USHORT          nFirst;
    USHORT          nDummyAlign1;
    MemoryBlock*  pNext;
    char            aData[1];

 static void* operator new(size_t, USHORT nTypes, USHORT nUnitSize)
 {
  return ::operator new(sizeof(MemoryBlock) + nTypes * nUnitSize);
 }
 static void  operator delete(void *p, size_t)
 {
  ::operator delete (p);
 }

 MemoryBlock (USHORT nTypes = 1, USHORT nUnitSize = 0);
 ~MemoryBlock() {}
};
 

此內存池的數據結構如圖6-2所示。

 

圖6-2 內存池的數據結構

6.2.2 總體機制

此內存池的總體機制如下。

（1）在運行過程中，MemoryPool內存池可能會有多個用來滿足內存申請請求的內存塊，這些內存塊是從進程堆中開辟的一個較大的連續內存區域，它由一個MemoryBlock結構體和多個可供分配的內存單元組成，所有內存塊組成了一個內存塊鏈表，MemoryPool的pBlock是這個鏈表的頭。對每個內存塊，都可以通過其頭部的MemoryBlock結構體的pNext成員訪問緊跟在其后面的那個內存塊。

（2）每個內存塊由兩部分組成，即一個MemoryBlock結構體和多個內存分配單元。這些內存分配單元大小固定（由MemoryPool的nUnitSize表示），MemoryBlock結構體并不維護那些已經分配的單元的信息；相反，它只維護沒有分配的自由分配單元的信息。它有兩個成員比較重要：nFree和nFirst。nFree記錄這個內存塊中還有多少個自由分配單元，而nFirst則記錄下一個可供分配的單元的編號。每一個自由分配單元的頭兩個字節（即一個USHORT型值）記錄了緊跟它之后的下一個自由分配單元的編號，這樣，通過利用每個自由分配單元的頭兩個字節，一個MemoryBlock中的所有自由分配單元被鏈接起來。

（3）當有新的內存請求到來時，MemoryPool會通過pBlock遍歷MemoryBlock鏈表，直到找到某個MemoryBlock所在的內存塊，其中還有自由分配單元（通過檢測MemoryBlock結構體的nFree成員是否大于0）。如果找到這樣的內存塊，取得其MemoryBlock的nFirst值（此為該內存塊中第1個可供分配的自由單元的編號）。然后根據這個編號定位到該自由分配單元的起始位置（因為所有分配單元大小固定，因此每個分配單元的起始位置都可以通過編號分配單元大小來偏移定位），這個位置就是用來滿足此次內存申請請求的內存的起始地址。但在返回這個地址前，需要首先將該位置開始的頭兩個字節的值（這兩個字節值記錄其之后的下一個自由分配單元的編號）賦給本內存塊的MemoryBlock的nFirst成員。這樣下一次的請求就會用這個編號對應的內存單元來滿足，同時將此內存塊的MemoryBlock的nFree遞減1，然后才將剛才定位到的內存單元的起始位置作為此次內存請求的返回地址返回給調用者。

（4）如果從現有的內存塊中找不到一個自由的內存分配單元（當第1次請求內存，以及現有的所有內存塊中的所有內存分配單元都已經被分配時會發生這種情形），MemoryPool就會從進程堆中申請一個內存塊（這個內存塊包括一個MemoryBlock結構體，及緊鄰其后的多個內存分配單元，假設內存分配單元的個數為n，n可以取值MemoryPool中的nInitSize或者nGrowSize），申請完后，并不會立刻將其中的一個分配單元分配出去，而是需要首先初始化這個內存塊。初始化的操作包括設置MemoryBlock的nSize為所有內存分配單元的大小（注意，并不包括MemoryBlock結構體的大小）、nFree為n-1（注意，這里是n-1而不是n，因為此次新內存塊就是為了滿足一次新的內存請求而申請的，馬上就會分配一塊自由存儲單元出去，如果設為n-1，分配一個自由存儲單元后無須再將n遞減1），nFirst為1（已經知道nFirst為下一個可以分配的自由存儲單元的編號。為1的原因與nFree為n-1相同，即立即會將編號為0的自由分配單元分配出去。現在設為1，其后不用修改nFirst的值），MemoryBlock的構造需要做更重要的事情，即將編號為0的分配單元之后的所有自由分配單元鏈接起來。如前所述，每個自由分配單元的頭兩個字節用來存儲下一個自由分配單元的編號。另外，因為每個分配單元大小固定，所以可以通過其編號和單元大小（MemoryPool的nUnitSize成員）的乘積作為偏移值進行定位。現在唯一的問題是定位從哪個地址開始？答案是MemoryBlock的aData[1]成員開始。因為aData[1]實際上是屬于MemoryBlock結構體的（MemoryBlock結構體的最后一個字節），所以實質上，MemoryBlock結構體的最后一個字節也用做被分配出去的分配單元的一部分。因為整個內存塊由MemoryBlock結構體和整數個分配單元組成，這意味著內存塊的最后一個字節會被浪費，這個字節在圖6-2中用位于兩個內存的最后部分的濃黑背景的小塊標識。確定了分配單元的起始位置后，將自由分配單元鏈接起來的工作就很容易了。即從aData位置開始，每隔nUnitSize大小取其頭兩個字節，記錄其之后的自由分配單元的編號。因為剛開始所有分配單元都是自由的，所以這個編號就是自身編號加1，即位置上緊跟其后的單元的編號。初始化后，將此內存塊的第1個分配單元的起始地址返回，已經知道這個地址就是aData。

（5）當某個被分配的單元因為delete需要回收時，該單元并不會返回給進程堆，而是返回給MemoryPool。返回時，MemoryPool能夠知道該單元的起始地址。這時，MemoryPool開始遍歷其所維護的內存塊鏈表，判斷該單元的起始地址是否落在某個內存塊的地址范圍內。如果不在所有內存地址范圍內，則這個被回收的單元不屬于這個MemoryPool；如果在某個內存塊的地址范圍內，那么它會將這個剛剛回收的分配單元加到這個內存塊的MemoryBlock所維護的自由分配單元鏈表的頭部，同時將其nFree值遞增1。回收后，考慮到資源的有效利用及后續操作的性能，內存池的操作會繼續判斷：如果此內存塊的所有分配單元都是自由的，那么這個內存塊就會從MemoryPool中被移出并作為一個整體返回給進程堆；如果該內存塊中還有非自由分配單元，這時不能將此內存塊返回給進程堆。但是因為剛剛有一個分配單元返回給了這個內存塊，即這個內存塊有自由分配單元可供下次分配，因此它會被移到MemoryPool維護的內存塊的頭部。這樣下次的內存請求到來，MemoryPool遍歷其內存塊鏈表以尋找自由分配單元時，第1次尋找就會找到這個內存塊。因為這個內存塊確實有自由分配單元，這樣可以減少MemoryPool的遍歷次數。

綜上所述，每個內存池（MemoryPool）維護一個內存塊鏈表（單鏈表），每個內存塊由一個維護該內存塊信息的塊頭結構（MemoryBlock）和多個分配單元組成，塊頭結構MemoryBlock則進一步維護一個該內存塊的所有自由分配單元組成的"鏈表"。這個鏈表不是通過"指向下一個自由分配單元的指針"鏈接起來的，而是通過"下一個自由分配單元的編號"鏈接起來，這個編號值存儲在該自由分配單元的頭兩個字節中。另外，第1個自由分配單元的起始位置并不是MemoryBlock結構體"后面的"第1個地址位置，而是MemoryBlock結構體"內部"的最后一個字節aData（也可能不是最后一個，因為考慮到字節對齊的問題），即分配單元實際上往前面錯了一位。又因為MemoryBlock結構體后面的空間剛好是分配單元的整數倍，這樣依次錯位下去，內存塊的最后一個字節實際沒有被利用。這么做的一個原因也是考慮到不同平臺的移植問題，因為不同平臺的對齊方式可能不盡相同。即當申請MemoryBlock大小內存時，可能會返回比其所有成員大小總和還要大一些的內存。最后的幾個字節是為了"補齊"，而使得aData成為第1個分配單元的起始位置，這樣在對齊方式不同的各種平臺上都可以工作。

6.2.3 細節剖析

有了上述的總體印象后，本節來仔細剖析其實現細節。

（1）MemoryPool的構造如下：

MemoryPool::MemoryPool( USHORT _nUnitSize,
                            USHORT _nInitSize, USHORT _nGrowSize )
{
    pBlock      = NULL;             ①
    nInitSize   = _nInitSize;       ②
    nGrowSize   = _nGrowSize;       ③

    if ( _nUnitSize > 4 )
        nUnitSize = (_nUnitSize + (MEMPOOL_ALIGNMENT-1)) & ~(MEMPOOL_ALIGNMENT-1); ④
    else if ( _nUnitSize <= 2 )
        nUnitSize = 2;              ⑤
    else
        nUnitSize = 4;
}
 

從①處可以看出，MemoryPool創建時，并沒有立刻創建真正用來滿足內存申請的內存塊，即內存塊鏈表剛開始時為空。

②處和③處分別設置"第1次創建的內存塊所包含的分配單元的個數"，及"隨后創建的內存塊所包含的分配單元的個數"，這兩個值在MemoryPool創建時通過參數指定，其后在該MemoryPool對象生命周期中一直不變。

后面的代碼用來設置nUnitSize，這個值參考傳入的_nUnitSize參數。但是還需要考慮兩個因素。如前所述，每個分配單元在自由狀態時，其頭兩個字節用來存放"其下一個自由分配單元的編號"。即每個分配單元"最少"有"兩個字節"，這就是⑤處賦值的原因。④處是將大于4個字節的大小_nUnitSize往上"取整到"大于_nUnitSize的最小的MEMPOOL_ ALIGNMENT的倍數（前提是MEMPOOL_ALIGNMENT為2的倍數）。如_nUnitSize為11時，MEMPOOL_ALIGNMENT為8，nUnitSize為16；MEMPOOL_ALIGNMENT為4，nUnitSize為12；MEMPOOL_ALIGNMENT為2，nUnitSize為12，依次類推。

（2）當向MemoryPool提出內存請求時：

void* MemoryPool::Alloc()
{
    if ( !pBlock )           ①
    {
   ……       
    }

    MemoryBlock* pMyBlock = pBlock;
    while (pMyBlock && !pMyBlock->nFree )②
        pMyBlock = pMyBlock->pNext;

    if ( pMyBlock )          ③
    {
        char* pFree = pMyBlock->aData+(pMyBlock->nFirst*nUnitSize);   
        pMyBlock->nFirst = *((USHORT*)pFree);
       
        pMyBlock->nFree--; 
        return (void*)pFree;
    }
    else                    ④
    {
        if ( !nGrowSize )
            return NULL;

  pMyBlock = new(nGrowSize, nUnitSize) FixedMemBlock(nGrowSize, nUnitSize);
        if ( !pMyBlock )
            return NULL;

        pMyBlock->pNext = pBlock;
        pBlock = pMyBlock;

        return (void*)(pMyBlock->aData);
    }

}
 

MemoryPool滿足內存請求的步驟主要由四步組成。

①處首先判斷內存池當前內存塊鏈表是否為空，如果為空，則意味著這是第1次內存申請請求。這時，從進程堆中申請一個分配單元個數為nInitSize的內存塊，并初始化該內存塊（主要初始化MemoryBlock結構體成員，以及創建初始的自由分配單元鏈表，下面會詳細分析其代碼）。如果該內存塊申請成功，并初始化完畢，返回第1個分配單元給調用函數。第1個分配單元以MemoryBlock結構體內的最后一個字節為起始地址。

②處的作用是當內存池中已有內存塊（即內存塊鏈表不為空）時遍歷該內存塊鏈表，尋找還有"自由分配單元"的內存塊。

③處檢查如果找到還有自由分配單元的內存塊，則"定位"到該內存塊現在可以用的自由分配單元處。"定位"以MemoryBlock結構體內的最后一個字節位置aData為起始位置，以MemoryPool的nUnitSize為步長來進行。找到后，需要修改MemoryBlock的nFree信息（剩下來的自由分配單元比原來減少了一個），以及修改此內存塊的自由存儲單元鏈表的信息。在找到的內存塊中，pMyBlock->nFirst為該內存塊中自由存儲單元鏈表的表頭，其下一個自由存儲單元的編號存放在pMyBlock->nFirst指示的自由存儲單元（亦即剛才定位到的自由存儲單元）的頭兩個字節。通過剛才定位到的位置，取其頭兩個字節的值，賦給pMyBlock->nFirst，這就是此內存塊的自由存儲單元鏈表的新的表頭，即下一次分配出去的自由分配單元的編號（如果nFree大于零的話）。修改維護信息后，就可以將剛才定位到的自由分配單元的地址返回給此次申請的調用函數。注意，因為這個分配單元已經被分配，而內存塊無須維護已分配的分配單元，因此該分配單元的頭兩個字節的信息已經沒有用處。換個角度看，這個自由分配單元返回給調用函數后，調用函數如何處置這塊內存，內存池無從知曉，也無須知曉。此分配單元在返回給調用函數時，其內容對于調用函數來說是無意義的。因此幾乎可以肯定調用函數在用這個單元的內存時會覆蓋其原來的內容，即頭兩個字節的內容也會被抹去。因此每個存儲單元并沒有因為需要鏈接而引入多余的維護信息，而是直接利用單元內的頭兩個字節，當其分配后，頭兩個字節也可以被調用函數利用。而在自由狀態時，則用來存放維護信息，即下一個自由分配單元的編號，這是一個有效利用內存的好例子。

④處表示在②處遍歷時，沒有找到還有自由分配單元的內存塊，這時，需要重新向進程堆申請一個內存塊。因為不是第一次申請內存塊，所以申請的內存塊包含的分配單元個數為nGrowSize，而不再是nInitSize。與①處相同，先做這個新申請內存塊的初始化工作，然后將此內存塊插入MemoryPool的內存塊鏈表的頭部，再將此內存塊的第1個分配單元返回給調用函數。將此新內存塊插入內存塊鏈表的頭部的原因是該內存塊還有很多可供分配的自由分配單元（除非nGrowSize等于1，這應該不太可能。因為內存池的含義就是一次性地從進程堆中申請一大塊內存，以供后續的多次申請），放在頭部可以使得在下次收到內存申請時，減少②處對內存塊的遍歷時間。

可以用圖6-2的MemoryPool來展示MemoryPool::Alloc的過程。圖6-3是某個時刻MemoryPool的內部狀態。

 

圖6-3 某個時刻MemoryPool的內部狀態

因為MemoryPool的內存塊鏈表不為空，因此會遍歷其內存塊鏈表。又因為第1個內存塊里有自由的分配單元，所以會從第1個內存塊中分配。檢查nFirst，其值為m，這時pBlock->aData+(pBlock->nFirst*nUnitSize)定位到編號為m的自由分配單元的起始位置（用pFree表示）。在返回pFree之前，需要修改此內存塊的維護信息。首先將nFree遞減1，然后取得pFree處開始的頭兩個字節的值（需要說明的是，這里aData處值為k。其實不是這一個字節。而是以aData和緊跟其后的另外一個字節合在一起構成的一個USHORT的值，不可誤會）。發現為k，這時修改pBlock的nFirst為k。然后，返回pFree。此時MemoryPool的結構如圖6-4所示。

圖6-4 MemoryPool的結構

 

圖6-4 MemoryPool的結構

可以看到，原來的第1個可供分配的單元（m編號處）已經顯示為被分配的狀態。而pBlock的nFirst已經指向原來m單元下一個自由分配單元的編號，即k。

（3）MemoryPool回收內存時：

void MemoryPool::Free( void* pFree )
{
    ……

    MemoryBlock* pMyBlock = pBlock;

    while ( ((ULONG)pMyBlock->aData > (ULONG)pFree) ||
         ((ULONG)pFree >= ((ULONG)pMyBlock->aData + pMyBlock->nSize)) )①
    {
         ……
    }

    pMyBlock->nFree++;                     ②
    *((USHORT*)pFree) = pMyBlock->nFirst;  ③
    pMyBlock->nFirst = (USHORT)(((ULONG)pFree-(ULONG)(pBlock->aData)) / nUnitSize);④

    if (pMyBlock->nFree*nUnitSize == pMyBlock->nSize )⑤
    {
        ……
    }
    else
    {
        ……
    }
}
 

如前所述，回收分配單元時，可能會將整個內存塊返回給進程堆，也可能將被回收分配單元所屬的內存塊移至內存池的內存塊鏈表的頭部。這兩個操作都需要修改鏈表結構。這時需要知道該內存塊在鏈表中前一個位置的內存塊。

①處遍歷內存池的內存塊鏈表，確定該待回收分配單元（pFree）落在哪一個內存塊的指針范圍內，通過比較指針值來確定。

運行到②處，pMyBlock即找到的包含pFree所指向的待回收分配單元的內存塊（當然，這時應該還需要檢查pMyBlock為NULL時的情形，即pFree不屬于此內存池的范圍，因此不能返回給此內存池，讀者可以自行加上）。這時將pMyBlock的nFree遞增1，表示此內存塊的自由分配單元多了一個。

③處用來修改該內存塊的自由分配單元鏈表的信息，它將這個待回收分配單元的頭兩個字節的值指向該內存塊原來的第一個可分配的自由分配單元的編號。

④處將pMyBlock的nFirst值改變為指向這個待回收分配單元的編號，其編號通過計算此單元的起始位置相對pMyBlock的aData位置的差值，然后除以步長（nUnitSize）得到。

實質上，③和④兩步的作用就是將此待回收分配單元"真正回收"。值得注意的是，這兩步實際上是使得此回收單元成為此內存塊的下一個可分配的自由分配單元，即將它放在了自由分配單元鏈表的頭部。注意，其內存地址并沒有發生改變。實際上，一個分配單元的內存地址無論是在分配后，還是處于自由狀態時，一直都不會變化。變化的只是其狀態（已分配/自由），以及當其處于自由狀態時在自由分配單元鏈表中的位置。

⑤處檢查當回收完畢后，包含此回收單元的內存塊的所有單元是否都處于自由狀態，且此內存是否處于內存塊鏈表的頭部。如果是，將此內存塊整個的返回給進程堆，同時修改內存塊鏈表結構。

注意，這里在判斷一個內存塊的所有單元是否都處于自由狀態時，并沒有遍歷其所有單元，而是判斷nFree乘以nUnitSize是否等于nSize。nSize是內存塊中所有分配單元的大小，而不包括頭部MemoryBlock結構體的大小。這里可以看到其用意，即用來快速檢查某個內存塊中所有分配單元是否全部處于自由狀態。因為只需結合nFree和nUnitSize來計算得出結論，而無須遍歷和計算所有自由狀態的分配單元的個數。

另外還需注意的是，這里并不能比較nFree與nInitSize或nGrowSize的大小來判斷某個內存塊中所有分配單元都為自由狀態，這是因為第1次分配的內存塊（分配單元個數為nInitSize）可能被移到鏈表的后面，甚至可能在移到鏈表后面后，因為某個時間其所有單元都處于自由狀態而被整個返回給進程堆。即在回收分配單元時，無法判定某個內存塊中的分配單元個數到底是nInitSize還是nGrowSize，也就無法通過比較nFree與nInitSize或nGrowSize的大小來判斷一個內存塊的所有分配單元是否都為自由狀態。

以上面分配后的內存池狀態作為例子，假設這時第2個內存塊中的最后一個單元需要回收（已被分配，假設其編號為m，pFree指針指向它），如圖6-5所示。

不難發現，這時nFirst的值由原來的0變為m。即此內存塊下一個被分配的單元是m編號的單元，而不是0編號的單元（最先分配的是最新回收的單元，從這一點看，這個過程與棧的原理類似，即先進后出。只不過這里的"進"意味著"回收"，而"出"則意味著"分配"）。相應地，m的"下一個自由單元"標記為0，即內存塊原來的"下一個將被分配出去的單元"，這也表明最近回收的分配單元被插到了內存塊的"自由分配單元鏈表"的頭部。當然，nFree遞增1。

圖6-5 分配后的內存池狀態

處理至⑥處之前，其狀態如圖6-6所示。

 

這里需要注意的是，雖然pFree被"回收"，但是pFree仍然指向m編號的單元，這個單元在回收過程中，其頭兩個字節被覆寫，但其他部分的內容并沒有改變。而且從整個進程的內存使用角度來看，這個m編號的單元的狀態仍然是"有效的"。因為這里的"回收"只是回收給了內存池，而并沒有回收給進程堆，因此程序仍然可以通過pFree訪問此單元。但是這是一個很危險的操作，因為首先該單元在回收過程中頭兩個字節已被覆寫，并且該單元可能很快就會被內存池重新分配。因此回收后通過pFree指針對這個單元的訪問都是錯誤的，讀操作會讀到錯誤的數據，寫操作則可能會破壞程序中其他地方的數據，因此需要格外小心。

接著，需要判斷該內存塊的內部使用情況，及其在內存塊鏈表中的位置。如果該內存塊中省略號"……"所表示的其他部分中還有被分配的單元，即nFree乘以nUnitSize不等于nSize。因為此內存塊不在鏈表頭，因此還需要將其移到鏈表頭部，如圖6-7所示。

圖6-7 因回收引起的MemoryBlock移動

 

如果該內存塊中省略號"……"表示的其他部分中全部都是自由分配單元，即nFree乘以nUnitSize等于nSize。因為此內存塊不在鏈表頭，所以此時需要將此內存塊整個回收給進程堆，回收后內存池的結構如圖6-8所示。

圖6-8 回收后內存池的結構

一個內存塊在申請后會初始化，主要是為了建立最初的自由分配單元鏈表，下面是其詳細代碼：

MemoryBlock::MemoryBlock (USHORT nTypes, USHORT nUnitSize)
 : nSize  (nTypes * nUnitSize),
   nFree  (nTypes - 1),                     ④
   nFirst (1),                              ⑤
   pNext  (0)
{
  char * pData = aData;                  ①
  for (USHORT i = 1; i < nTypes; i++) ②
  {
   *reinterpret_cast<USHORT*>(pData) = i; ③
   pData += nUnitSize;
  }
}
 

這里可以看到，①處pData的初值是aData，即0編號單元。但是②處的循環中i卻是從1開始，然后在循環內部的③處將pData的頭兩個字節值置為i。即0號單元的頭兩個字節值為1，1號單元的頭兩個字節值為2，一直到（nTypes-2）號單元的頭兩個字節值為（nTypes-1）。這意味著內存塊初始時，其自由分配單元鏈表是從0號開始。依次串聯，一直到倒數第2個單元指向最后一個單元。

還需要注意的是，在其初始化列表中，nFree初始化為nTypes-1（而不是nTypes），nFirst初始化為1（而不是0）。這是因為第1個單元，即0編號單元構造完畢后，立刻會被分配。另外注意到最后一個單元初始并沒有設置頭兩個字節的值，因為該單元初始在本內存塊中并沒有下一個自由分配單元。但是從上面例子中可以看到，當最后一個單元被分配并回收后，其頭兩個字節會被設置。

圖6-9所示為一個內存塊初始化后的狀態。

圖6-9 一個內存塊初始化后的狀態

 

當內存池析構時，需要將內存池的所有內存塊返回給進程堆：

MemoryPool::~MemoryPool()
{
    MemoryBlock* pMyBlock = pBlock;
    while ( pMyBlock )
    {
        ……
    }
}
 

6.2.4 使用方法

分析內存池的內部原理后，本節說明如何使用它。從上面的分析可以看到，該內存池主要有兩個對外接口函數，即Alloc和Free。Alloc返回所申請的分配單元（固定大小內存），Free則回收傳入的指針代表的分配單元的內存給內存池。分配的信息則通過MemoryPool的構造函數指定，包括分配單元大小、內存池第1次申請的內存塊中所含分配單元的個數，以及內存池后續申請的內存塊所含分配單元的個數等。

綜上所述，當需要提高某些關鍵類對象的申請／回收效率時，可以考慮將該類所有生成對象所需的空間都從某個這樣的內存池中開辟。在銷毀對象時，只需要返回給該內存池。"一個類的所有對象都分配在同一個內存池對象中"這一需求很自然的設計方法就是為這樣的類聲明一個靜態內存池對象，同時為了讓其所有對象都從這個內存池中開辟內存，而不是缺省的從進程堆中獲得，需要為該類重載一個new運算符。因為相應地，回收也是面向內存池，而不是進程的缺省堆，還需要重載一個delete運算符。在new運算符中用內存池的Alloc函數滿足所有該類對象的內存請求，而銷毀某對象則可以通過在delete運算符中調用內存池的Free完成。

6.2.5 性能比較

為了測試利用內存池后的效果，通過一個很小的測試程序可以發現采用內存池機制后耗時為297 ms。而沒有采用內存池機制則耗時625 ms，速度提高了52.48%。速度提高的原因可以歸結為幾點，其一，除了偶爾的內存申請和銷毀會導致從進程堆中分配和銷毀內存塊外，絕大多數的內存申請和銷毀都由內存池在已經申請到的內存塊中進行，而沒有直接與進程堆打交道，而直接與進程堆打交道是很耗時的操作；其二，這是單線程環境的內存池，可以看到內存池的Alloc和Free操作中并沒有加線程保護措施。因此如果類A用到該內存池，則所有類A對象的創建和銷毀都必須發生在同一個線程中。但如果類A用到內存池，類B也用到內存池，那么類A的使用線程可以不必與類B的使用線程是同一個線程。

另外，在第1章中已經討論過，因為內存池技術使得同類型的對象分布在相鄰的內存區域，而程序會經常對同一類型的對象進行遍歷操作。因此在程序運行過程中發生的缺頁應該會相應少一些，但這個一般只能在真實的復雜應用環境中進行驗證。

圖6-7 因回收引起的MemoryBlock移動

6.3 本章小結

內存的申請和釋放對一個應用程序的整體性能影響極大，甚至在很多時候成為某個應用程序的瓶頸。消除內存申請和釋放引起的瓶頸的方法往往是針對內存使用的實際情況提供一個合適的內存池。內存池之所以能夠提高性能，主要是因為它能夠利用應用程序的實際內存使用場景中的某些"特性"。比如某些內存申請與釋放肯定發生在一個線程中，某種類型的對象生成和銷毀與應用程序中的其他類型對象要頻繁得多，等等。針對這些特性，可以為這些特殊的內存使用場景提供量身定做的內存池。這樣能夠消除系統提供的缺省內存機制中，對于該實際應用場景中的不必要的操作，從而提升應用程序的整體性能。

 

圖6-6 處理至⑥處之前的內存池狀態

圖6-5 分配后的內存池狀態

 

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/rabbit729/archive/2009/02/23/3927979.aspx