Published by orzz.org(). (http://orzz.org/memory-pool-fixed/)
内存池是一种用来分配内存的池技术，重点在“池”，即内存的重用上。
重点不在“池”上的内存分配技术当然也是有的，比如stl的内存分配器（SGI STL使用了内存池，而有很多其他版本的STL则没有），重点在“分配器”的概念上。
内存的重用，能够带来不少好处。最为直观的好处是，提高内存分配/释放的速度；不大明显的好处，则是避免程序产生内存碎片（即空闲却又无法利用的内存）。
另外，由于内存池托管了内存分配，其实它属于内存分配器的一种，因此内存分配器的好处它也自然可以享受到。比如在内存分配的时候增加一些标记，可以使之支持内存泄露检测之类。
内存池根据各自的适用场景，又分为很多种：比如单线程/多线程的分类；又比如定长/变长的分类。
想要实现一个通用（即可以在各种场景下使用），又高效的内存池，不是一件容易的事情；学习、对比、然后使用第三方的内存池，也需要一定的时间成本。所以很多时候，在自己的代码里，又或实际的项目中，若非有确凿的证据表明内存管理方面存在不可忽视的瓶颈，否则大家使用的还是new/delete，或者malloc/free。
下面我们一起来实现一个简单的定长内存池，并尝试对它进行一些拓展。
1. 只分配固定大小内存的fixed_pool
我们先考虑一个最简单的内存池：不考虑单线程/多线程，不考虑分配大小可变，不考虑一个内存是否被回收两次，也不考虑回收的上限（即只从系统获取内存而不归还 —— 这其实在很多时候不会是一个问题，因为我们不会无限制的分配内存，而总是会一边分配一边释放，这样释放的内存就被保存起来供下次分配用）。
这么简单的内存池也是有它的适用场景的，比如在同一个线程里需要不停分配/释放同样大小内存块或对象的时候。
它的定义可以简单得像这个样子：
|
1 2 3 4 5 6 |
class fixed_pool { public: void* alloc(void); void free(void* p); }; |
通过它，我们只能干两件事情，那就是分配一块固定大小的内存，或者释放（回收）掉刚刚分配出来的内存。
那么，固定的大小如何传递呢？
通常有两种方法，一种是通过模板参数传递：
|
1 2 3 4 5 6 7 8 9 |
template <size_t BlockSize_> class fixed_pool { struct block_t { char buff_[BlockSize_]; block_t* next_; }; }; |
这种方法不需要额外的size_t成员来保存一个内存block的大小，在编译时这些信息就都被决定好了。
另一种是通过构造函数传递：
|
1 2 3 4 5 6 7 |
class fixed_pool { size_t block_size_; public: explicit fixed_pool(size_t block_size); }; |
虽然这样会消耗一个size_t的空间，但是不论把block的大小设为什么，fixed_pool的类型始终是不会有改变的。
为了方便后面使用它来构造通用的定长内存池，这里我使用第二种方法来定义fixed_pool。
那么block_size_的初始化过程如下：
|
1 2 3 4 5 6 7 8 9 |
public: explicit fixed_pool(size_t block_size) : block_size_(block_size) // ... { assert(block_size_ > sizeof(block_t*)); // 为了利用block的空间来存储结点指针 } size_t block_size(void) const { return block_size_; } |
接下来是最关键的地方了，alloc的实现。
想要实现alloc，首先要思考下我们用的分配算法。
最直观也最简单的一种想法是：
那么首先，需要定义链表结点和空闲链表头：
|
1 2 3 4 5 6 7 |
private: struct block_t { block_t* next_; }; block_t* free_list_; |
接下来就是alloc的实现：
|
1 2 3 4 5 6 7 8 9 10 11 |
void* alloc(void) { if (free_list_) { block_t* p = free_list_; free_list_ = free_list_->next_; return p; } else return malloc(block_size_); } |
在这里要注意malloc的大小是block_size_，而不是sizeof(block_t*) + block_size_。因为只要block_size_满足大于sizeof(block_t*)，结点本身的内存大小就足够存储下一个结点的指针了。而内存一旦被alloc出去之后，next_指针里的内存其实是不需要保存的（因为这里不检查内存的有效性，也没有其他的需求要求内存块离开内存池后需要通过它访问内存池内部的数据），可以认为一旦分配出去的内存，就和内存池无关了，只有当内存被归还之后，才需要用到这个next_指针。
最后是free的实现：
|
1 2 3 4 5 6 7 |
void free(void* p) { if (!p) return; block_t* new_block = (block_t*)p; new_block->next_ = free_list_; free_list_ = new_block; } |
好了，到了这里我们可以先写一小段测试代码来试探下这个简单内存池的性能。
想要测试内存分配性能，有几种常规做法，比如连续分配再连续释放，或蝶式分配释放（即随机分配释放）。这里采用蝶式分配释放来测试性能。
算法如下，先通过init函数初始化好随机索引数组，然后后面通过遍历这个随机的数组，就可以保证分配时的数据长度，和分配/释放都是随机的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
const int TestCont = 1000; const int TestLast = 10000; const int TestSMin = 1024; const int TestSMax = TestSMin/* * 1024*/; size_t size[TestLast] = { 0 }; size_t indx[TestLast] = { 0 }; nx::stopwatch<> sw; void init(int n = 1) { char str[256]; sprintf(str, "Cycles:\t\t%d\nContinuous:\t%d\nAlloc Size:\t%dByte-%.1fKB\nThreads:\t%d\n", TestCont, TestLast, TestSMin * sizeof(char), static_cast<double>(TestSMax * sizeof(char)) / 1024.0, n); cout << str << endl; nx::random<> rdm(TestSMin, TestSMax); for (int i = 0; i < TestLast; ++i) rdm.roll(size[i]); rdm.range(0, TestLast); for (int i = 0; i < TestLast; ++i) rdm.roll(indx[i]); } |
void init(int n = 1)的参数是预留的，为后面的多线程内存池测试做准备。
负责进行测试的算法如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
#define TEST_MEMPOOL(alloc_name, test_count) do { \ for(int i = 0; i < (int)(test_count / 2); ++i) \ { \ alloc_name alc; \ for(int x = 0; x < 2; ++x) /* 下面的for需要跑两次才是一次完整的 分配/释放 循环 */ \ for(int n = 0; n < TestLast; ++n) /* 因为在第一次的循环后，由于随机的关系，会有一部分内存不会被free掉 */ \ { /* 这些没有被销毁的内存，将会在第二次的循环中被销毁 */ \ void*(& p) = test[indx[n]]; /* 简单想一下就可以明白，第二次和第一次的 分配/释放 正好是相反的 */ \ if (p) \ { \ alc.free(p); \ p = 0; \ } \ else \ p = alc.alloc(size[n]); \ } \ } } while(0) template <typename A> void start(const char* out) { void* (test[TestLast]) = { 0 }; cout << out; sw.start(); TEST_MEMPOOL(A, TestCont); cout << sw.value() * 1000 << " ms" << endl; } |
最后，还需要两个外敷的wrapper，用来包裹出统一的测试接口：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
struct new_alloc { void* alloc(size_t size) { return new char[size]; } void free(void* p) { delete[](char*)p; } }; struct fixed_alloc { static fixed_pool pool_; void* alloc(size_t /*size*/) { return pool_.alloc(); } void free(void* p) { pool_.free(p); } }; fixed_pool fixed_alloc::pool_((TestSMax + TestSMin) / 2); |
测试代码中的stopwatch和random，是我自己实现的简单的秒表和随机数，代码可以在这里看到：
https://code.google.com/p/nixy/source/browse/trunk/nixycore/time/stopwatch.h
https://code.google.com/p/nixy/source/browse/trunk/nixycore/random/random.h
好了，现在可以来写一个简单的main函数，
|
1 2 3 4 5 6 7 8 9 10 11 |
int main(void) { using namespace test_mempool; init(); start<new_alloc> ("Start for new_alloc...\t\t"); start<fixed_alloc>("Start for fixed_alloc...\t"); return 0; } |
并跑一跑看看测试效果：
|
1 2 3 4 5 6 7 |
Cycles: 1000 Continuous: 10000 Alloc Size: 1024Byte-1.0KB Threads: 1 Start for new_alloc... 1373 ms Start for fixed_alloc... 125 ms |
测试平台：
编译环境：
在测试时为了公平，我特意把分配的大小固定在了1KB。从数据上看，fixed_pool比直接的new/delete要快一个数量级。
这里有几个细节，或者说上面的简单内存池的缺点：
上面的alloc算法，在不论多少次分配之后，若池里的内存不够了，都只会新申请一个block_size长度的内存。这意味着一次性的连续大量内存分配并不比系统的内存分配器好多少。而且从系统分配内存时,在分配时间间隔不确定的情况下，可能会让进程的内存碎片更严重。
向系统释放内存在一些应用场景里其实不是必要的。比如你在main函数中直接new int，严格来说并不算内存泄漏。没有delete的内存在程序退出后会由系统帮你妥妥的善后掉，不存在不能被其他程序使用的问题。
但同样是由于没有内存的释放过程，fixed_pool在使用时必须是单例形式，或者说全局的。由此，上面的测试外敷类fixed_alloc里使用了static静态成员的方法提供唯一的fixed_pool实例。
第一个问题需要改进前面的内存分配算法：在每次需要扩充容量时，都获取一大块内存，在这一大块内存上划分出链表结构，形成free_list_。
第二个问题则可以通过不同的模板配置来解决：通过传入一个模板参数，来配置fixed_pool是否在析构时向系统释放其中的内存。若在使用时只需要一个全局的内存分配入口点，那么系统释放内存就是不必要的，反之则是必要的。
下面先来解决第一个问题。
2. 在需要时申请一大块连续内存
fixed_pool的alloc接口可以改成这个样子：
|
1 2 3 4 5 6 7 8 |
void* alloc(void) { if (!free_list_) expand(); assert(free_list_); block_t* p = free_list_; free_list_ = free_list_->next_; return p; } |
这样，就把“在需要时获取一大块内存”的expand部分从alloc里单独抽出来了。
现在的fixed_pool，expand算法是这样的：
|
1 2 3 4 5 6 |
void expand(void) { free_list_ = static_cast<blocks_t*>(malloc(block_size_)); assert(free_list_); free_list_->next_ = NULL; } |
改进一下算法，很简单就可以调整成每次分配10个block_size_长度的内存：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
void expand(void) { static const size_t COUNT = 10; free_list_ = static_cast<blocks_t*>(malloc(block_size_ * COUNT)); assert(free_list_); block_t* p = free_list_; for(size_t i = 0; i < COUNT - 1; ++i) { /* p->next_ = p + block_size_; // 直接在内存块上划分出链表结点 p = p->next_; */ p = p->next_ = (block_t*)(((char*)p) + block_size_); } p->next_ = NULL; } |
可以很容易发现，count固定为10是一个不好的做法。好的做法应当是修改为某个预测模型：比如vector的内部实现里，一般在每次需要扩充内存的时候，会将当前的内存容量翻倍。
这一类的算法，要求expand根据被调用的次数决定count的值，因此count不能再是一个常量或局部变量了。
为了保持fixed_pool代码的整洁，可以把expand的具体实现交给一个Policy。这样fixed_pool就不需要关注该如何expand，只需要维护free_list_链表就可以了。
抽象出上述预测模型的Policy可以像这样：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
struct use_expand_default { private: size_t count_; protected: use_expand_default(void) : count_(1) {} size_t count(void) const { return count_; } char* expand(size_t block_size) { assert(block_size); /* count_ *= 2; return malloc(block_size * count_); */ return malloc(block_size * (count_ <<= 1)); } }; |
这是个非常简单的模型。每次调用expand的时候，内部都会自动将count_翻倍，然后返回更大的内存块。
如果实际需要的话，后面可以很方便的实现并应用其它预测模型，比如以斐波那契数列（Fibonacci）方式增长的预测模型。
fixed_pool和expand修改一下就可以使用这个模型了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
template <class Expand_> class fixed_pool : Expand_ { // ...... void expand(void) { free_list_ = static_cast<block_t*>(Expand_::expand(block_size_)); assert(free_list_); block_t* p = free_list_; for(size_t i = 0; i < Expand_::count() - 1; ++i) { /* p->next_ = p + block_size_; p = p->next_; */ p = p->next_ = (block_t*)(((char*)p) + block_size_); } p->next_ = NULL; } // ...... }; |
expand里面用来在一整块内存上构建链表的算法，其实和boost.pool、loki里的小内存分配器的基础算法是异曲同工的。
使用新的fixed_pool测试的结果：
|
1 2 3 4 5 6 7 |
Cycles: 1000 Continuous: 10000 Alloc Size: 1024Byte-1.0KB Threads: 1 Start for new_alloc... 1389 ms Start for fixed_alloc... 234 ms |
由于expand需要提前构建空闲链表，而第一个版本则没有这个开销，所以平均来说会比第一次慢不少，不过速度仍然是new/delete的6倍左右。
接下来解决上面提到的第二个问题。
3. 支持内存的归还
前面在解决第一个问题的时候，已经把fixed_pool改写成了一个可以根据Policy变化算法的类了。
因此这里只需要构建一个可以自动释放内存的Policy就行了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
struct use_expand_return : use_expand_default { private: typedef use_expand_default base_t; struct blocks_t { char* block_; blocks_t* pnext_; } * phead_; protected: use_expand_return(void) : phead_(NULL) {} ~use_expand_return(void) { while(phead_) { blocks_t* block = phead_; phead_ = phead_->pnext_; free(block->block_); free(block); } } char* expand(size_t block_size) { blocks_t* new_block = static_cast<blocks_t*>(malloc(sizeof(blocks_t))); new_block->block_ = base_t::expand(block_size); new_block->pnext_ = phead_; phead_ = new_block; return (new_block->block_); } }; |
这个策略也不复杂，其实就是构建了一个链表，把每次expand返回的内存块串了起来，然后再在析构的时候把它们销毁掉。
归还策略的fixed_pool的测试用alloc就不再需要static了：
|
1 2 3 4 5 6 7 |
struct return_alloc { fixed_pool<use_expand_return> pool_; return_alloc(void) : pool_((TestSMax + TestSMin) / 2) {} void* alloc(size_t /*size*/) { return pool_.alloc(); } void free(void* p) { pool_.free(p); } }; |
下面对它做一下测试（同时使用new/delete、expand_default和expand_return）：
|
1 2 3 4 5 6 7 8 |
Cycles: 1000 Continuous: 10000 Alloc Size: 1024Byte-1.0KB Threads: 1 Start for new_alloc... 1357 ms Start for fixed_alloc... 234 ms Start for return_alloc... 1201 ms |
可以发现，速度不升反降，变得和new/delete相差无几了。
观察下测试算法，里面是在每两次test循环之后，析构一次alloc。相对于new/delete，expand_return其实就是把零碎的分配/释放集中在了一起完成。
从测试结果上可以看出来，一次大内存释放，和多次的小内存释放比起来，并没有什么性能优势。
稍微修改一下测试方法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#define TEST_MEMPOOL(alloc_name, test_count) do { \ for(int i = 0; i < (int)(test_count / 10); ++i) \ { \ alloc_name alc; \ for(int x = 0; x < 10; ++x) /* 这里被改为10次，则alc对象析构的频度也降为前面的1/5 */ \ for(int n = 0; n < TestLast; ++n) \ { \ void*(& p) = test[indx[n]]; \ if (p) \ { \ alc.free(p); \ p = 0; \ } \ else \ p = alc.alloc(size[n]); \ } \ } } while(0) |
然后再跑一次测试：
|
1 2 3 4 5 6 7 8 |
Cycles: 1000 Continuous: 10000 Alloc Size: 1024Byte-1.0KB Threads: 1 Start for new_alloc... 1357 ms Start for fixed_alloc... 219 ms Start for return_alloc... 437 ms |
return_alloc的速度一下子快了3倍。所以说，对于内存池而言，应当尽量不要频繁的把内存归还给系统，否则内存池的预存储意义就不大了。
4. 利用fixed_pool构建多级分配
早期Loki的SmallObjAllocator，是使用一个数组存储各种长度的FixedAllocator（和上文的fixed_pool类似），数组下标和FixedAllocator的分配长度没有直接关系。从SmallObjAllocator申请内存和回收内存，都需要使用二分查找定位合适的FixedAllocator。
现在的Loki更换了算法，直接使用(256 + 4 - 1) / 4 = 64个FixedAllocator组成的数组，数组中的每个FixedAllocator分配的内存依次递增4 byte。这样就不再需要二分查找的开销，直接通过简单的计算就可以快速定位合适的FixedAllocator。
我们可以模仿它的做法，将内存分为3级：
第一级用于分配小内存，使用64个fixed_pool，内存大小以sizeof(void*)为单位递增，32位系统里最大就能够分配到256bytes；
第二级用于分配大内存，也使用64个fixed_pool，采用64bytes为分配间隔，最大能够分配到4KB；
更大的内存将被分类到第三级，由默认的new/delete处理。
Loki的内存释放接口带有一个size_t参数，需要指定待释放内存的大小。若不指定大小，则会导致一次线性搜索。
而这里的目标是让mem_pool的接口和malloc/free保持一致。为了避免线性搜索，只好采用空间换时间的做法，在每个分配的内存块的头部放入一个size_t来保存此内存块的大小。
先定义出mem_pool需要的这些配置，以及外部接口：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
class mem_pool { public: static const size_t SMALL_NUM = 64; static const size_t SMALL_INC = sizeof(void*); static const size_t SMALL_SIZ = SMALL_NUM * SMALL_INC; static const size_t LARGE_NUM = 64; static const size_t LARGE_INC = SMALL_SIZ; static const size_t LARGE_SIZ = LARGE_NUM * LARGE_INC; static const size_t TOTAL_NUM = SMALL_NUM + LARGE_NUM - 1; private: struct alloc_t { size_t size_; }; // 内存块类型，定义出头部 typedef fixed_pool<use_expand_default> pool_t; // 因为mem_pool将作为全局内存池，所以不考虑内存释放 pool_t* (pools_[TOTAL_NUM]); // 指针数组，存储所有的fixed_pool public: void* alloc(size_t size); void free(void* p); void* realloc(void* p, size_t size); }; |
然后，在mem_pool的构造函数里，分配出pools_数组的每个元素，并在析构函数释放资源：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public: mem_pool(void) { size_t n = sizeof(alloc_t) + SMALL_INC; for(size_t i = 0; i < SMALL_NUM; ++i, n += SMALL_INC) { pools_[i] = new pool_t(n); assert(pools_[i]); } n += LARGE_INC - SMALL_INC; for(size_t i = SMALL_NUM; i < TOTAL_NUM; ++i, n += LARGE_INC) { pools_[i] = new pool_t(n); assert(pools_[i]); } } ~mem_pool(void) { for(size_t i = 0; i < TOTAL_NUM; ++i) delete pools_[i]; } |
这是在常数时间内根据分配大小定位一个fixed_pool的算法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
private: pool_t* find_pool(size_t size) { size_t n; if (size <= SMALL_SIZ) { n = ((size - 1) / SMALL_INC); } else if (size <= LARGE_SIZ) { size -= SMALL_SIZ; n = ((size - 1) / LARGE_INC) + SMALL_NUM; } else return NULL; return pools_[n]; } |
有了上面这些东西，现在可以很轻松的实现出alloc和free：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
private: void* cast(alloc_t* p) { return static_cast<void*>(p + 1); } alloc_t* cast(void* p) { return static_cast<alloc_t*>(p) - 1; } public: void* alloc(size_t size) { if (size == 0) return NULL; pool_t* pool = find_pool(size); alloc_t* alc_p = static_cast<alloc_t*>(pool ? pool->alloc() : malloc(sizeof(alloc_t) + size)); assert(alc_p); alc_p->size_ = size; return cast(alc_p); } void free(void* p) { alloc_t* alc_p = cast(p); pool_t* pool = find_pool(alc_p->size_); if (pool) pool->free(alc_p); else ::free(alc_p); } |
先测试一下，定义一个mem_pool_alloc：
|
1 2 3 4 5 6 7 |
struct mem_pool_alloc { static mem_pool pool_; void* alloc(size_t size) { return pool_.alloc(size); } void free(void* p) { pool_.free(p); } }; mem_pool mem_pool_alloc::pool_; |
然后运行：
|
1 2 3 4 5 6 7 8 |
Cycles: 1000 Continuous: 10000 Alloc Size: 1024Byte-1.0KB Threads: 1 Start for new_alloc... 1326 ms Start for fixed_alloc... 234 ms Start for mem_pool_alloc... 250 ms |
可以看到mem_pool和fixed_pool的速度相差无几。
下面把Alloc Size调整为4Byte-1.0KB，再试试：
|
1 2 3 4 5 6 7 |
Cycles: 1000 Continuous: 10000 Alloc Size: 4Byte-1.0KB Threads: 1 Start for new_alloc... 1497 ms Start for mem_pool_alloc... 249 ms |
最后，我们来实现realloc。realloc稍显复杂，首先，把realloc的“外壳”搭建出来：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
public: void* realloc(void* p, size_t size) { if (p) { if (size == 0) { this->free(p); return NULL; } return do_realloc(p, size); } return alloc(size); } |
然后，真正的realloc算法可以单独抽取出来在do_realloc里实现，这样代码整体会比较清爽：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
private: alloc_t* mem_move(alloc_t* dst, alloc_t* src, pool_t* src_pool) { assert(src_pool); memcpy(dst + 1, src + 1, src->size_); src_pool->free(src); return dst; } void* do_realloc(void* p, size_t size) { alloc_t* old_p = cast(p); pool_t* old_pool = find_pool(old_p->size_); pool_t* new_pool = find_pool(size); if (new_pool && !old_pool) return p; if (new_pool) { /* (old_pool != NULL) */ if (old_pool->block_size() >= new_pool->block_size()) return p; /* (old_pool != new_pool) */ alloc_t* new_p = (alloc_t*)new_pool->alloc(); assert(new_p); new_p->size_ = size; return cast(mem_move(new_p, old_p, old_pool)); } /* (new_pool == NULL) */ if (old_pool) { alloc_t* new_p = (alloc_t*)malloc(sizeof(alloc_t) + size); assert(new_p); new_p->size_ = size; return cast(mem_move(new_p, old_p, old_pool)); } /* (new_pool == old_pool == NULL) */ return cast((alloc_t*)::realloc(old_p, sizeof(alloc_t) + size)); } |
为了测试realloc，前面的测试算法需要调整一下：
|
1 2 3 4 5 6 7 8 9 10 11 |
#define TEST_MEMPOOL(alloc_name, test_count) do { \ for(int i = 0; i < (int)(test_count / 2); ++i) \ { \ alloc_name alc; \ for(int x = 0; x < 2; ++x) \ for(int n = 0; n < TestLast; ++n) \ { \ void*(& p) = test[indx[n]]; \ p = alc.realloc(p, size[n]); \ } \ } } while(0) |
然后在测试用的alloc内分别包装出realloc语义：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
struct new_alloc { void* realloc(void* p, size_t size) { if (p) delete [] (char*)p; else return new char[size]; return 0; } }; struct mem_pool_alloc { static mem_pool pool_; void* realloc(void* p, size_t size) { if (p) pool_.free(p); else return pool_.alloc(size); return 0; } }; mem_pool mem_pool_alloc::pool_; struct mem_pool_realloc { static mem_pool pool_; void* realloc(void* p, size_t size) { return pool_.realloc(p, size); } }; mem_pool mem_pool_realloc::pool_; |
测试结果：
|
1 2 3 4 5 6 7 8 |
Cycles: 1000 Continuous: 10000 Alloc Size: 4Byte-1.0KB Threads: 1 Start for new_alloc... 1560 ms Start for mem_pool_alloc... 250 ms Start for mem_pool_realloc... 187 ms |
可以看到，使用realloc又比一般的alloc/free要快了不少。
本文简单的介绍了定长内存池的相关设计，变长内存池等其它类型的内存池后文中再慢慢展开。
参考文章：
Published by orzz.org(). (http://orzz.org/memory-pool-fixed/)
受教了！呵呵！