內存池的實現(一)

1.引言

　　C/C++下內存管理是讓幾乎每個程序員頭疼的問題，分配足夠的內存、追蹤內存的分配、在不須要的時候釋放內存——這個任務至關複雜。而直接使用系統調用malloc/free、new/delete進行內存分配和釋放，有如下弊端：

　　　　A.調用malloc/new,系統須要根據「最早匹配」、「最優匹配」或其餘算法在內存空閒塊表中查找一塊空閒內存，調用free/delete,系統可能須要合併空閒內存塊，這些會產生額外開銷

　　　　B.頻繁使用時會產生大量內存碎片，從而下降程序運行效率

　　　　C.容易形成內存泄漏

　　內存池（memory pool)是代替直接調用malloc/free、new/delete進行內存管理的經常使用方法，當咱們申請內存空間時，首先到咱們的內存池中查找合適的內存塊，而不是直接向操做系統申請，優點在於：

　　　　A.比malloc/free進行內存申請/釋放的方式快

　　　　B.不會產生或不多產生堆碎片

　　　　C.可避免內存泄漏

2.內存池設計

　　看到內存池好處這麼多，是否是恨不能立刻拋棄malloc/free，投奔內存池的懷抱呢？且慢，在咱們本身動手實現內存池以前還須要明確如下幾個問題：

　　　　A.內存池的空間如何得到？是程序啓動時分配一大塊空間仍是程序運行中按需求分配？

　　　　B.內存池對到來的內存申請，有沒有大小的限制？若是有，最小可申請的內存塊爲多大，最大的呢？

　　　　C.如何合理設計內存塊結構，方便咱們進行內存的申請、追蹤和釋放呢？

　　　　D.內存池佔用越多空間，相對應其餘程序能使用的內存就越少，是否要設定內存池空間的上限？設定爲多少合適呢？

　　帶着以上問題，咱們來看如下一種內存池設計方案。

3.內存池實現方案一

　　從這裏下載該內存池實現的源碼。

　　首先給出該方案的總體架構，以下：

　　　　　　　　　　　　　　　　圖1.內存池架構圖

　　結構中主要包含block、list 和pool這三個結構體，block結構包含指向實際內存空間的指針，前向和後向指針讓block可以組成雙向鏈表；list結構中free指針指向空閒 內存塊組成的鏈表，used指針指向程序使用中的內存塊組成的鏈表，size值爲內存塊的大小，list之間組成單向鏈表；pool結構記錄list鏈表的頭和尾。

4.內存跟蹤策略

　　該方案中，在進行內存分配時，將多申請12個字節，即實際申請的內存大小爲所需內存大小+12。在多申請的12個字節中，分別存放對應的list指針（4字節）、used指針（4字節）和校驗碼（4字節）。經過這樣設定，咱們很容易獲得該塊內存所在的list和block，校驗碼起到粗略檢查是否出錯的做用。該結構圖示以下：

　　　　　　　　　　　　圖2.內存塊申請示意圖

圖中箭頭指示的位置爲內存塊真正開始的位置。

5.內存申請和釋放策略

5.1 申請

　　申請：根據所申請內存的大小，遍歷list鏈表，查看是否存在相匹配的size；

　　　　A.存在匹配size：查看free時候爲NULL

　　　　　　free爲NULL：使用malloc/new申請內存，並將其置於used所指鏈表的尾部

　　　　　　free不爲NULL：將free所指鏈表的頭結點移除，放置於used所指鏈表的尾部

　　　　B.不存在匹配size：新建list，使用malloc/new申請內存，並將其置於該list的used所指鏈表尾部

　　　　　　返回內存空間指針

5.2 釋放

　　釋放：根據內存跟蹤策略，獲取list指針和used指針，將其從used指針所指的鏈表中刪除，放置於free指針所指向的鏈表

6.對方案一的分析

　　對照「內存池設計」一節中提出的問題，咱們的方案一有如下特色：

　　　　A.程序啓動後內存池並無內存塊，到程序真正進行內存申請和釋放的時候才接管內存塊管理；

　　　　B.該內存池對到來的申請，對申請大小並不作限制，其爲每一個size值建立鏈表進行內存管理；

　　　　C.該方案沒有提供限定內存池大小的功能

　　結合分析，能夠得出該方案應用場景以下：程序所申請的內存塊大小比較固定（好比只申請/釋放1024bytes或2048bytes的內存），申請和釋放的頻率基本保持一致（因申請多而釋放少會佔用過多內存，最終致使系統崩潰）。

 　　這篇文章講解了內存管理的基本知識，以一個簡單的內存池實現例子做爲敲門磚，引領你們認識內存池，下一篇爲內存池進階文章，講解apache服務器中內存池的實現方法。

 

原文連接:http://www.cnblogs.com/bangerlee/archive/2011/08/31/2161421.html