內存池技術

 看到一篇關於內存池技術的介紹文章，受益不淺，轉貼至此。

  原貼地址：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 分配後的內存池狀態