C/C++下內存管理是讓幾乎每一個程序員頭疼的問題，分配足夠的內存、追蹤內存的分配、在不需要的時候釋放內存——這個任務相當復雜。而直接使用系統調用malloc/free、new/delete進行內存分配和釋放，有以下弊端：
A.調用malloc/new,系統需要根據“最先匹配”、“最優匹配”或其他算法在內存空閒塊表中查找一塊空閒內存，調用free/delete,系統可能需要合並空閒內存塊，這些會產生額外開銷
B.頻繁使用時會產生大量內存碎片，從而降低程序運行效率
C.容易造成內存洩漏
內存池（memory pool)是代替直接調用malloc/free、new/delete進行內存管理的常用方法，當我們申請內存空間時，首先到我們的內存池中查找合適的內存塊，而不是直接向操作系統申請，優勢在於：
A.比malloc/free進行內存申請/釋放的方式快
B.不會產生或很少產生堆碎片
C.可避免內存洩漏
看到內存池好處這麼多，是不是恨不能馬上拋棄malloc/free，投奔內存池的懷抱呢？且慢，在我們自己動手實現內存池之前還需要明確以下幾個問題：
A.內存池的空間如何獲得？是程序啟動時分配一大塊空間還是程序運行中按需求分配？
B.內存池對到來的內存申請，有沒有大小的限制？如果有，最小可申請的內存塊為多大，最大的呢？
C.如何合理設計內存塊結構，方便我們進行內存的申請、追蹤和釋放呢？
D.內存池占用越多空間，相對應其他程序能使用的內存就越少，是否要設定內存池空間的上限？設定為多少合適呢？
帶著以上問題，我們來看以下一種內存池設計方案。
從這裡下載該內存池實現的源碼。
首先給出該方案的整體架構，如下：
圖1.內存池架構圖
結構中主要包含block、list 和pool這三個結構體，block結構包含指向實際內存空間的指針，前向和後向指針讓block能夠組成雙向鏈表；list結構中free指針指向空閒 內存塊組成的鏈表，used指針指向程序使用中的內存塊組成的鏈表，size值為內存塊的大小，list之間組成單向鏈表；pool結構記錄list鏈表的頭和尾。
該方案中，在進行內存分配時，將多申請12個字節，即實際申請的內存大小為所需內存大小+12。在多申請的12個字節中，分別存放對應的list指針（4字節）、used指針（4字節）和校驗碼（4字節）。通過這樣設定，我們很容易得到該塊內存所在的list和block，校驗碼起到粗略檢查是否出錯的作用。該結構圖示如下：
圖2.內存塊申請示意圖
圖中箭頭指示的位置為內存塊真正開始的位置。
申請：根據所申請內存的大小，遍歷list鏈表，查看是否存在相匹配的size；
A.存在匹配size：查看free時候為NULL
free為NULL：使用malloc/new申請內存，並將其置於used所指鏈表的尾部
free不為NULL：將free所指鏈表的頭結點移除，放置於used所指鏈表的尾部
B.不存在匹配size：新建list，使用malloc/new申請內存，並將其置於該list的used所指鏈表尾部
返回內存空間指針
釋放：根據內存跟蹤策略，獲取list指針和used指針，將其從used指針所指的鏈表中刪除，放置於free指針所指向的鏈表
對照“內存池設計”一節中提出的問題，我們的方案一有以下特點：
A.程序啟動後內存池並沒有內存塊，到程序真正進行內存申請和釋放的時候才接管內存塊管理；
B.該內存池對到來的申請，對申請大小並不做限制，其為每個size值創建鏈表進行內存管理；
C.該方案沒有提供限定內存池大小的功能
結合分析，可以得出該方案應用場景如下：程序所申請的內存塊大小比較固定（比如只申請/釋放1024bytes或2048bytes的內存），申請和釋放的頻率基本保持一致（因申請多而釋放少會占用過多內存，最終導致系統崩潰）。
這篇文章講解了內存管理的基本知識，以一個簡單的內存池實現例子作為敲門磚，引領大家認識內存池，下一篇為內存池進階文章，講解apache服務器中內存池的實現方法。
原文鏈接:http://www.cnblogs.com/bangerlee/archive/2011/08/31/2161421.html
