內存池的實現(一)

引言

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

  1. 調用malloc/new,系統需要根據“最先匹配”、“最優匹配”或其他算法在內存空閒塊表中查找一塊空閒內存,調用free/delete,系統可能需要合併空閒內存塊,這些會產生額外開銷
  2. 頻繁使用時會產生大量內存碎片,從而降低程序運行效率
  3. 容易造成內存泄漏

 

內存池(memory pool)是代替直接調用malloc/freenew/delete進行內存管理的常用方法,當我們申請內存空間時,首先到我們的內存池中查找合適的內存塊,而不是直接向操作系統申請,優勢在於:

  1. 比malloc/free進行內存申請/釋放的方式快
  2. 不會產生或很少產生堆碎片
  3. 可避免內存泄漏

 

內存池設計

看到內存池好處這麼多,是不是恨不能馬上拋棄malloc/free,投奔內存池的懷抱呢?且慢,在我們自己動手實現內存池之前還需要明確以下幾個問題:

  1. 內存池的空間如何獲得?是程序啓動時分配一大塊空間還是程序運行中按需求分配?
  2. 內存池對到來的內存申請,有沒有大小的限制?如果有,最小可申請的內存塊爲多大,最大的呢?
  3. 如何合理設計內存塊結構,方便我們進行內存的申請、追蹤和釋放呢?
  4. 內存池佔用越多空間,相對應其他程序能使用的內存就越少,是否要設定內存池空間的上限?設定爲多少合適呢?

 

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

 

內存池實現方案一

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

首先給出該方案的整體架構,如下:

內存池實現架構

圖1.內存池架構圖

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

 

內存跟蹤策略

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

結點頭12字節說明

圖2.內存塊申請示意圖

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

 

內存申請和釋放策略

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

    存在匹配size:查看free時候爲NULL

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

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

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

   返回內存空間指針

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

 

對方案一的分析

對照“內存池設計”一節中提出的問題,我們的方案一有以下特點:

  1. 程序啓動後內存池並沒有內存塊,到程序真正進行內存申請和釋放的時候才接管內存塊管理;
  2. 該內存池對到來的申請,對申請大小並不做限制,其爲每個size值創建鏈表進行內存管理;
  3. 該方案沒有提供限定內存池大小的功能

 

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

 

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章