內(nèi)存池在棧結構中的性能設計實現(xiàn)

一、概述

在 C/C++ 中，內(nèi)存管理是一個非常棘手的問題，我們在編寫一個程序的時候幾乎不可避免的要遇到內(nèi)存的分配邏輯，這時候隨之而來的有這樣一些問題：是否有足夠的內(nèi)存可供分配?分配失敗了怎么辦? 如何管理自身的內(nèi)存使用情況? 等等一系列問題。在一個高可用的軟件中，如果我們僅僅單純的向操作系統(tǒng)去申請內(nèi)存，當出現(xiàn)內(nèi)存不足時就退出軟件，是明顯不合理的。

正確的思路應該是在內(nèi)存不足的時，考慮如何管理并優(yōu)化自身已經(jīng)使用的內(nèi)存，這樣才能使得軟件變得更加可用。本次項目我們將實現(xiàn)一個內(nèi)存池，并使用一個棧結構來測試我們的內(nèi)存池提供的分配性能。最終，我們要實現(xiàn)的內(nèi)存池在棧結構中的性能，要遠高于使用 std::allocator 和 std::vector，如下圖所示：

項目涉及的知識點

C++ 中的內(nèi)存分配器 std::allocator

內(nèi)存池技術

手動實現(xiàn)模板鏈式棧

鏈式棧和列表棧的性能比較

內(nèi)存池簡介

內(nèi)存池是池化技術中的一種形式。通常我們在編寫程序的時候回使用 new delete 這些關鍵字來向操作系統(tǒng)申請內(nèi)存，而這樣造成的后果就是每次申請內(nèi)存和釋放內(nèi)存的時候，都需要和操作系統(tǒng)的系統(tǒng)調(diào)用打交道，從堆中分配所需的內(nèi)存。如果這樣的操作太過頻繁，就會找成大量的內(nèi)存碎片進而降低內(nèi)存的分配性能，甚至出現(xiàn)內(nèi)存分配失敗的情況。

而內(nèi)存池就是為了解決這個問題而產(chǎn)生的一種技術。從內(nèi)存分配的概念上看，內(nèi)存申請無非就是向內(nèi)存分配方索要一個指針，當向操作系統(tǒng)申請內(nèi)存時，

操作系統(tǒng)需要進行復雜的內(nèi)存管理調(diào)度之后，才能正確的分配出一個相應的指針。而這個分配的過程中，我們還面臨著分配失敗的風險。

所以，每一次進行內(nèi)存分配，就會消耗一次分配內(nèi)存的時間，設這個時間為 T，那么進行 n 次分配總共消耗的時間就是 nT；如果我們一開始就確定好我們可能需要多少內(nèi)存，那么在最初的時候就分配好這樣的一塊內(nèi)存區(qū)域，當我們需要內(nèi)存的時候，直接從這塊已經(jīng)分配好的內(nèi)存中使用即可，那么總共需要的分配時間僅僅只有 T。當 n 越大時，節(jié)約的時間就越多。

二、主函數(shù)設計

我們要設計實現(xiàn)一個高性能的內(nèi)存池，那么自然避免不了需要對比已有的內(nèi)存，而比較內(nèi)存池對內(nèi)存的分配性能，就需要實現(xiàn)一個需要對內(nèi)存進行動態(tài)分配的結構（比如：鏈表棧），為此，可以寫出如下的代碼：

在上面的兩段代碼中，StackAlloc 是一個鏈表棧，接受兩個模板參數(shù)，第一個參數(shù)是棧中的元素類型，第二個參數(shù)就是棧使用的內(nèi)存分配器。

因此，這個內(nèi)存分配器的模板參數(shù)就是整個比較過程中唯一的變量，使用默認分配器的模板參數(shù)為 std::allocator，而使用內(nèi)存池的模板參數(shù)為 MemoryPool。

std::allocator 是 C++標準庫中提供的默認分配器，他的特點就在于我們在 使用 new 來申請內(nèi)存構造新對象的時候，勢必要調(diào)用類對象的默認構造函數(shù)，而使用 std::allocator 則可以將內(nèi)存分配和對象的構造這兩部分邏輯給分離開來，使得分配的內(nèi)存是原始、未構造的。

下面我們來實現(xiàn)這個鏈表棧。

三、模板鏈表棧

棧的結構非常的簡單，沒有什么復雜的邏輯操作，其成員函數(shù)只需要考慮兩個基本的操作：入棧、出棧。為了操作上的方便，我們可能還需要這樣一些方法：判斷棧是否空、清空棧、獲得棧頂元素。

簡單的邏輯諸如構造、析構、判斷棧是否空、返回棧頂元素的邏輯都非常簡單，直接在上面的定義中實現(xiàn)了，下面我們來實現(xiàn) clear(), push() 和 pop() 這三個重要的邏輯：

至此，我們完成了整個模板鏈表棧，現(xiàn)在我們可以先注釋掉 main() 函數(shù)中使用內(nèi)存池部分的代碼來測試這個連表棧的內(nèi)存分配情況，我們就能夠得到這樣的結果：

在使用 std::allocator 的默認內(nèi)存分配器中，在

#define ELEMS 10000000
#define REPS 100

的條件下，總共花費了近一分鐘的時間。

如果覺得花費的時間較長，不愿等待，則你嘗試可以減小這兩個值

總結

本節(jié)我們實現(xiàn)了一個用于測試性能比較的模板鏈表棧，目前的代碼如下。在下一節(jié)中，我們開始詳細實現(xiàn)我們的高性能內(nèi)存池。

二、設計內(nèi)存池

在上一節(jié)實驗中，我們在模板鏈表棧中使用了默認構造器來管理棧操作中的元素內(nèi)存，一共涉及到了 rebind::other, allocate(), dealocate(), construct(), destroy()這些關鍵性的接口。所以為了讓代碼直接可用，我們同樣應該在內(nèi)存池中設計同樣的接口：

在上面的類設計中可以看到，在這個內(nèi)存池中，其實是使用鏈表來管理整個內(nèi)存池的內(nèi)存區(qū)塊的。內(nèi)存池首先會定義固定大小的基本內(nèi)存區(qū)塊(Block)，然后在其中定義了一個可以實例化為存放對象內(nèi)存槽的對象槽（Slot_）和對象槽指針的一個聯(lián)合。然后在區(qū)塊中，定義了四個關鍵性質(zhì)的指針，它們的作用分別是：

currentBlock_: 指向當前內(nèi)存區(qū)塊的指針

currentSlot_: 指向當前內(nèi)存區(qū)塊中的對象槽

lastSlot_: 指向當前內(nèi)存區(qū)塊中的最后一個對象槽

freeSlots_: 指向當前內(nèi)存區(qū)塊中所有空閑的對象槽

梳理好整個內(nèi)存池的設計結構之后，我們就可以開始實現(xiàn)關鍵性的邏輯了。

三、實現(xiàn)

MemoryPool::construct() 實現(xiàn)

MemoryPool::construct() 的邏輯是最簡單的，我們需要實現(xiàn)的，僅僅只是調(diào)用信件對象的構造函數(shù)即可，因此：

MemoryPool::deallocate() 實現(xiàn)

MemoryPool::deallocate() 是在對象槽中的對象被析構后才會被調(diào)用的，主要目的是銷毀內(nèi)存槽。其邏輯也不復雜：

MemoryPool::~MemoryPool() 實現(xiàn)

析構函數(shù)負責銷毀整個內(nèi)存池，因此我們需要逐個刪除掉最初向操作系統(tǒng)申請的內(nèi)存塊：

MemoryPool::allocate() 實現(xiàn)

MemoryPool::allocate() 毫無疑問是整個內(nèi)存池的關鍵所在，但實際上理清了整個內(nèi)存池的設計之后，其實現(xiàn)并不復雜。具體實現(xiàn)如下：

四、與 std::vector 的性能對比

我們知道，對于棧來說，鏈棧其實并不是最好的實現(xiàn)方式，因為這種結構的棧不可避免的會涉及到指針相關的操作，同時，還會消耗一定量的空間來存放節(jié)點之間的指針。事實上，我們可以使用 std::vector 中的 push_back() 和 pop_back() 這兩個操作來模擬一個棧，我們不妨來對比一下這個 std::vector 與我們所實現(xiàn)的內(nèi)存池在性能上誰高誰低，我們在 主函數(shù)中加入如下代碼：

這時候，我們重新編譯代碼，就能夠看出這里面的差距了：

首先是使用默認分配器的鏈表棧速度最慢，其次是使用 std::vector 模擬的棧結構，在鏈表棧的基礎上大幅度削減了時間。

std::vector 的實現(xiàn)方式其實和內(nèi)存池較為類似，在 std::vector 空間不夠用時，會拋棄現(xiàn)在的內(nèi)存區(qū)域重新申請一塊更大的區(qū)域，并將現(xiàn)在內(nèi)存區(qū)域中的數(shù)據(jù)整體拷貝一份到新區(qū)域中。

最后，對于我們實現(xiàn)的內(nèi)存池，消耗的時間最少，即內(nèi)存分配性能最佳，完成了本項目。

總結

本節(jié)中，我們實現(xiàn)了我們上節(jié)實驗中未實現(xiàn)的內(nèi)存池，完成了整個項目的目標。 這個內(nèi)存池不僅精簡而且高效，整個內(nèi)存池的完整代碼如下：

審核編輯：劉清