1. 项目概述为什么我们需要多尺寸内存池在C的世界里内存管理是每个开发者绕不开的坎。new和delete看似简单但在高并发、高性能的场景下频繁地向操作系统申请和释放小块内存性能开销会变得非常可观。这不仅仅是几次函数调用的开销更涉及到操作系统的锁竞争、内存碎片化以及缓存局部性变差等一系列问题。如果你写过服务器后端、游戏引擎或者任何对性能有苛刻要求的程序大概率都遇到过内存分配成为性能瓶颈的情况。“多尺寸内存池”就是为了解决这个问题而生的。它不是一个单一尺寸的固定池而是一个能高效管理多种不同大小内存块的分配器。想象一下你的程序需要频繁分配8字节、16字节、32字节、64字节等不同大小的对象。如果为每一种尺寸都维护一个独立的、线程安全的分配器那么当需要分配一个24字节的对象时你可能会选择32字节的池虽然有一些内部碎片但分配和释放的速度极快且避免了向系统频繁申请。这就是多尺寸内存池的核心价值用空间少量的内部碎片换取时间极快的分配速度和系统资源的稳定性减少碎片和系统调用。我最初接触这个概念是在优化一个高频交易系统的中间件时。当时的性能分析显示超过15%的CPU时间花在了malloc和free上。在尝试了多种开源内存池后发现要么功能过于复杂要么对特定尺寸的支持不够好于是决定自己动手设计实现一个。今天分享的这套设计方案和实现细节就是经过多个项目迭代后的产物它足够轻量、高效并且易于集成到现有项目中。2. 核心设计思路与架构拆解一个优秀的多尺寸内存池设计目标必须明确快速分配/释放、减少内存碎片、支持多线程、易于管理。围绕这些目标我设计了以下核心架构。2.1 分级内存池策略这是整个设计的基石。我们不采用一个大的堆来切割而是预先定义一系列“尺寸等级”。常见的策略是采用2的幂次方8 16 32 64 128 256...或者混合间隔8 16 24 32 48 64...。我选择了后者因为2的幂次方在64字节之后内部碎片率会急剧上升。例如一个65字节的对象需要128字节的空间浪费了近50%。我的尺寸等级设计如下8 16 24 32 48 64 96 128 192 256 384 512... 在较小尺寸时增长平缓较大尺寸时按比例增长力求在碎片和池数量之间取得平衡。每个尺寸等级都对应一个独立的“内存池”。每个池管理固定大小的内存块。当一个分配请求到来时内存池会向上对齐到最近的尺寸等级。例如请求30字节会分配到32字节的池中。2.2 线程本地存储与全局后备池多线程环境是性能杀手。如果所有线程都竞争同一个全局内存池的锁那么内存池带来的性能优势将荡然无存。因此线程本地存储Thread Local Storage TLS是关键。我的设计是每个线程都拥有自己的一套“线程本地内存池”用于快速分配和释放。这些本地池的内存最初来源于一个“全局后备池”。当线程本地池空闲时其内存块不会立即还给系统而是保持在本地供该线程下次使用。只有当线程退出时才将大量空闲内存块返还给全局后备池。这样大部分分配和释放操作都发生在线程本地是无锁的速度极快。只有当线程本地池耗尽或需要批量归还内存时才需要与全局后备池交互而这类操作频率较低。2.3 内存块的组织自由链表每个尺寸等级的内存池内部如何管理无数个相同大小的内存块答案是单链表自由链表Free List。我们并不需要为每个内存块维护复杂的元数据。在分配时我们将一个空闲内存块返回给用户在释放时用户将这块内存还给我们。妙处在于在空闲状态下这块内存本身就可以用来存储链表指针我们将空闲内存块的头几个字节例如一个void*作为next指针指向下一个空闲块。池子本身只需要维护一个头指针free_list_head指向第一个空闲块。分配从free_list_head取出一个块将头指针指向下一个块然后返回这个块的地址。释放将待释放块的next指针指向当前的free_list_head然后将free_list_head指向这个待释放块。这个过程只有几次指针操作复杂度是O(1)。这也是内存池速度远超系统malloc的主要原因之一。2.4 大块内存的分配与池的扩容内存池不能无限预分配。当某个尺寸等级的线程本地池和全局后备池都为空时就需要向操作系统申请新的内存。我们不会一次只申请一个块那样效率太低。我的策略是批量申请一次申请一大块内存例如一个“Chunk”或“Page”比如64KB然后将这块内存切割成无数个固定大小的小块串入自由链表。这个“大块内存”本身需要被记录和管理以便在池子销毁或内存紧缩时能完整地归还给操作系统。因此我们需要一个额外的结构来管理这些“大块”Chunk。3. 关键数据结构与类设计接下来我们深入到代码层面看看如何用C实现上述设计。我将核心组件分为四个类MemoryBlock、FixedSizePool、ThreadCache和MultiSizeMemoryPool。3.1 MemoryBlock自由链表的节点它不是一个显式声明的类而是一个概念。任何一块由池分配出去的内存在空闲时其起始地址都被解释为一个MemoryBlock*。// 这是一个概念上的结构并不需要实际定义 struct MemoryBlock { MemoryBlock* next; // 指向下一个空闲块 // 注意这里没有其他数据。当块被分配给用户后用户数据将覆盖这里。 };分配时我们返回(void*)(block)。释放时用户传回的指针ptr我们可以直接转为(MemoryBlock*)ptr然后操作其next指针。3.2 FixedSizePool固定尺寸内存池这是管理单一尺寸内存池的核心类。它需要知道块大小block_size并维护一个自由链表。同时它还需要记录所有申请来的大块内存Chunks以便最终释放。class FixedSizePool { private: size_t block_size_; // 每个内存块的大小 MemoryBlock* free_list_; // 自由链表头指针 std::vectorvoid* chunks_; // 记录所有申请的大块内存 // 禁止拷贝 FixedSizePool(const FixedSizePool) delete; FixedSizePool operator(const FixedSizePool) delete; public: explicit FixedSizePool(size_t block_size); ~FixedSizePool(); void* Allocate(); void Deallocate(void* ptr); // 当自由链表为空时向系统申请一批新内存块 void Refill(); size_t GetBlockSize() const { return block_size_; } };Refill()函数的实现是关键向操作系统申请一大块内存例如使用::operator new或malloc。一次申请的大小可以是block_size_ * 64或直接申请一个页面如64KB。将这块大内存Chunk记录到chunks_向量中。将这块大内存切割成多个block_size_大小的块并将每个块链接到free_list_上。注意事项这里存在一个对齐问题。我们申请的大块内存起始地址可能并不满足所有类型的内存对齐要求。一个稳健的做法是在申请时使用std::aligned_allocC17或平台特定的API如posix_memalign来确保内存对齐。在我的实现中为了简化我让每个block_size_本身也是对齐的比如对齐到8字节或alignof(std::max_align_t)并且大块内存按这个对齐值申请。对于绝大多数情况这已经足够。chunks_的管理在析构函数~FixedSizePool()中需要遍历chunks_将每一块大内存都归还给操作系统。绝对不要只归还自由链表上的块那样会导致已分配但未释放的内存块所在的大块内存无法被释放造成泄漏。3.3 ThreadCache线程本地缓存每个线程拥有一个ThreadCache对象它包含一个FixedSizePool的数组或向量每个元素对应一个尺寸等级。class ThreadCache { private: // 指向各个尺寸池的指针数组。索引通过尺寸映射函数计算。 std::arrayFixedSizePool*, kNumSizeClasses pools_; // 全局内存池的引用用于当线程缓存需要扩容时申请内存 MultiSizeMemoryPool global_pool_; public: explicit ThreadCache(MultiSizeMemoryPool global_pool); ~ThreadCache(); void* Allocate(size_t size); void Deallocate(void* ptr, size_t size); };核心函数Allocate的逻辑根据请求的size通过一个映射函数SizeClassIndex(size)计算出应该使用哪个尺寸等级即pools_数组的索引。调用对应FixedSizePool的Allocate()方法。如果该池的自由链表为空即Allocate()返回nullptr则先调用该池的Refill()然后再分配。Deallocate逻辑同样根据size找到对应的FixedSizePool。调用其Deallocate(ptr)方法。这里有一个重要的优化点当线程本地池的空闲块过多时例如超过某个阈值应该将一部分块归还给全局后备池防止某个线程占用大量内存却不使用。这被称为“慢释放”或“垃圾回收”机制。可以在ThreadCache的Deallocate中增加计数当累计释放次数达到阈值时触发一次向全局池的归还操作。3.4 MultiSizeMemoryPool总控与全局后备这是对外的统一接口也是全局后备池的持有者。它负责管理所有尺寸等级的FixedSizePool作为全局后备并管理各个线程的ThreadCache。class MultiSizeMemoryPool { private: // 全局后备池每个尺寸一个 std::arraystd::unique_ptrFixedSizePool, kNumSizeClasses size_pools_; // 线程本地缓存的键。使用thread_local存储ThreadCache指针。 static thread_local ThreadCache* tls_cache_; // 用于保护全局池操作的互斥锁仅在必要时使用 std::mutex global_mutex_; // 预定义的尺寸等级数组 static const std::arraysize_t, kNumSizeClasses size_classes_; public: MultiSizeMemoryPool(); ~MultiSizeMemoryPool() default; // 注意需要谨慎处理线程退出顺序 void* Allocate(size_t size); void Deallocate(void* ptr, size_t size); // 供ThreadCache内部调用的全局Refill函数 void RefillFromGlobalPool(FixedSizePool* thread_pool, size_t size_class_index); private: // 根据大小计算尺寸等级索引 size_t SizeClassIndex(size_t size) const; };Allocate和Deallocate的实现 这两个函数非常简单几乎只是对ThreadCache的转发。void* MultiSizeMemoryPool::Allocate(size_t size) { if (tls_cache_ nullptr) { // 首次调用为该线程创建ThreadCache tls_cache_ new ThreadCache(*this); } return tls_cache_-Allocate(size); } void MultiSizeMemoryPool::Deallocate(void* ptr, size_t size) { // 即使ptr为nullptr也应由调用者保证这里我们假设不为空。 if (tls_cache_ nullptr) { // 理论上不应该发生但为安全起见可以fallback到全局池的释放 // 更简单的做法是直接调用系统的free ::operator delete(ptr); return; } tls_cache_-Deallocate(ptr, size); }RefillFromGlobalPool的实现 这是当线程本地池耗尽时向全局池申请一批块的函数。因为涉及共享的全局资源所以需要加锁。void MultiSizeMemoryPool::RefillFromGlobalPool(FixedSizePool* thread_pool, size_t size_class_index) { std::lock_guardstd::mutex lock(global_mutex_); auto* global_pool size_pools_[size_class_index].get(); // 策略1从全局池的自由链表中转移一批块到线程池。 // 策略2更简单直接让线程池自己向系统申请新的大块内存即调用thread_pool-Refill()。 // 这里采用策略2逻辑更清晰。 // 但策略1有助于平衡不同线程间的内存使用。 // 我们实现一个简单的策略1的变种从全局池“偷”一些块。 const int kBatchSize 32; // 一次转移的块数 void* batch[kBatchSize]; int num_fetched 0; for (int i 0; i kBatchSize; i) { void* block global_pool-Allocate(); // 从全局池分配 if (block) { batch[num_fetched] block; } else { break; // 全局池也空了 } } if (num_fetched 0) { // 将获取到的块加入到线程池的自由链表 for (int i 0; i num_fetched; i) { thread_pool-Deallocate(batch[i]); // 注意这里调用Deallocate是将其加入到线程池的空闲链表并非真释放。 } } else { // 全局池也空了线程池需要自己向系统申请 thread_pool-Refill(); } }4. 核心实现细节与避坑指南纸上谈兵终觉浅实现过程中充满了各种“坑”。下面我分享几个最关键的实现细节和对应的避坑经验。4.1 尺寸等级映射函数的设计如何快速地将一个分配请求大小size映射到对应的尺寸等级索引这是内存池分配操作中的第一个步骤必须高效。一个简单的方法是顺序遍历size_classes_数组找到第一个大于等于size的值。但这是O(n)的当尺寸等级较多时不可取。更高效的方法是使用查找表或数学计算。我的方案是混合策略对于小尺寸比如小于256字节使用查找表。因为尺寸等级是离散的数量有限。我可以预先计算一个数组lookup_table[256]其中lookup_table[size]直接存储对应的尺寸等级索引。这样映射就是O(1)。对于大尺寸大于等于256字节使用数学计算。因为我的尺寸等级在变大后间隔也变大可以用一个公式近似计算索引。例如index (size alignment - 1) / alignment的某种变体然后与一个边界值比较调整。size_t MultiSizeMemoryPool::SizeClassIndex(size_t size) const { if (size 256) { // 小尺寸查表假设我们有一个静态的全局查找表 static const uint8_t lookup[257] { /* 预计算好的索引值 */ }; return lookup[size]; } else { // 大尺寸计算 // 根据size_classes_的增长规律推导公式 // 例如size_classes_ [256, 384, 512, 768, 1024...] // 可以按区间计算 if (size 512) return kIndexFor512; else if (size 768) return kIndexFor768; // ... 以此类推或者用更数学化的方法 // 最终如果超过内存池管理的最大尺寸返回一个特殊值或触发fallback return kNumSizeClasses; // 表示需要fallback到系统malloc } }避坑指南边界处理一定要仔细处理size 0的情况。通常内存池会将其映射到最小块如8字节或直接返回nullptr。我建议返回最小块以兼容某些旧代码或特定库的行为。对齐保证映射后的块大小必须至少满足alignof(std::max_align_t)通常是8或16字节否则分配的内存可能无法用于某些需要严格对齐的类型如SSE/AVX数据。我的做法是让size_classes_数组中的所有尺寸都已经是向上对齐到这个值的。4.2 线程本地存储的初始化与清理使用thread_local变量tls_cache_非常方便但有一个致命问题析构顺序。当线程退出时thread_local对象会析构。如果tls_cache_在析构时试图访问正在析构或已析构的MultiSizeMemoryPool全局对象就会导致未定义行为通常是程序崩溃。解决方案使用静态全局内存池将MultiSizeMemoryPool设计为单例或全局静态对象利用“静态初始化顺序fiasco”的相反特性——函数内的静态局部变量在首次调用时初始化并且其析构顺序是可控的在main函数之后。但这种方法在多DLL加载的场景下可能有问题。使用原始指针和显式清理tls_cache_存储原始指针。在ThreadCache的析构函数中不主动将内存归还给可能已失效的全局池而是简单地将其持有的所有内存块“泄漏”掉或者记录到一个全局的“孤儿内存”列表由后续的进程清理这种方法比较hack。分离全局池的生命周期确保MultiSizeMemoryPool对象的生命周期长于所有使用它的线程。这通常意味着在main函数开始时就创建它并且永不主动销毁它或者只在程序明确退出时销毁。在我的实践中我采用方案3并结合一个优雅的ThreadCache清理回调。我使用pthread的特定键pthread_key_t或Windows的FlsFiber Local Storage回调机制在线程退出时自动调用一个函数来清理ThreadCache。在这个回调函数中我可以安全地将线程本地的大量空闲块归还给全局池因为此时全局池肯定还存在。// 伪代码示例 (POSIX) void DestructThreadCache(void* ptr) { ThreadCache* cache static_castThreadCache*(ptr); if (cache global_pool_is_alive) { // 需要一种方式检查全局池是否存活 cache-ReleaseAllToGlobal(); } delete cache; } // 创建键时设置析构回调 pthread_key_create(tls_key_, DestructThreadCache);实操心得 在多线程动态库中使用thread_local要格外小心。如果动态库被卸载dlclose而线程还在运行那么thread_local对象的析构函数将在一个已被卸载的代码段中执行必然崩溃。在这种情况下方案3确保全局对象生命周期和显式清理回调更为可靠。4.3 内存对齐与元数据开销我们之前提到空闲块利用自身空间存储next指针。这要求块的大小至少能放下一个指针。对于8字节的池在64位系统上指针大小也是8字节这刚好够用。但是当这个块被分配给用户后用户会在里面存储自己的数据。这没问题因为next指针已经被覆盖。关键在于对齐我们返回给用户的内存地址必须满足该内存将要存储的数据类型的对齐要求。C的new操作符返回的内存对齐到alignof(std::max_align_t)。我们的内存池至少应提供同样的保证。我的做法是在向系统申请大块内存Chunk时使用对齐分配如aligned_alloc。确保每个block_size_是对齐值的整数倍。在将大块内存切割成小块时每个小块的起始地址自然就是对齐的。元数据零开销这是自由链表设计的精髓。我们没有任何额外的“块头”来存储块大小或状态信息。这带来了一个严峻问题释放时如何知道块属于哪个池在Deallocate(void* ptr, size_t size)中我们通过参数size知道了块的大小从而找到了对应的池。但用户可能错误地传入错误的size或者使用malloc/free的兼容接口时根本没有size参数。解决方案强制传入size像C的operator delete(void* ptr, size_t size)一样要求调用者传递大小。这依赖于编译器或用户代码的正确性。嵌入隐式元数据在分配给用户的内存块前面偷偷藏一个小的头信息比如一个指向所属FixedSizePool的指针或者尺寸等级索引。这增加了每个块的内部开销比如8字节但对于稍大一点的块如32字节以上开销比例可以接受。全局地址映射查询维护一个类似std::unordered_mapvoid*, size_t的结构记录每个分配出去的地址对应的尺寸。但这在释放时需要查找性能很差。基于地址的启发式判断如果内存池是按大块Chunk组织的可以根据ptr的地址判断它落在哪个Chunk里而这个Chunk是属于某个特定尺寸池的。这需要额外的数据结构来记录Chunk到池的映射但查找可以优化例如Chunk按地址排序后用二分查找。对于追求极致性能且能控制接口的场景我选择方案1。对于需要兼容free(ptr)接口的场景我选择方案2即增加一个块头。虽然牺牲了一点空间但换来了安全性和兼容性在大多数应用中是可以接受的。5. 性能测试与对比分析设计实现完了是骡子是马得拉出来溜溜。我设计了一套性能测试方案与系统默认的malloc/free以及new/delete进行对比。测试环境Linux x86_64 GCC 11开启-O2优化。测试方法单线程连续分配释放循环分配和释放固定大小如32字节的内存块计算每秒操作数Ops。多线程随机分配释放多个线程并发运行随机分配不同大小在池管理的尺寸范围内的内存块并在随机时间后释放测试在压力下的吞吐量和延迟。内存碎片化测试长时间运行模拟工作负载后观察进程的虚拟内存大小VSS和常驻内存大小RSS并与系统分配器对比。测试结果概要单线程性能对于小对象256B的分配/释放内存池的速度通常是系统malloc的5到20倍。这是因为省去了系统调用的开销和复杂的内存布局算法。多线程性能优势更加明显。由于线程本地无锁操作在高并发下如16个线程性能可以是系统分配器的数十倍并且CPU时间更多地花在业务逻辑而非内存管理上。内存占用在稳定状态下内存池的内存占用RSS可能略高于系统分配器因为池会预留一些空闲块。但是其内存增长更加稳定不易出现内存碎片化导致的内存空间激增。系统malloc在应对大量小对象随机分配释放时VSS可能会持续增长外部碎片而内存池的VSS增长则呈现阶梯式更为可控。一个具体的测试代码片段单线程#include chrono #include iostream #include “MultiSizeMemoryPool.h” void benchmark_system(size_t block_size, int iterations) { auto start std::chrono::high_resolution_clock::now(); for (int i 0; i iterations; i) { void* p std::malloc(block_size); // 模拟使用 *(static_castchar*(p)) a; std::free(p); } auto end std::chrono::high_resolution_clock::now(); auto duration std::chrono::duration_caststd::chrono::microseconds(end - start); std::cout System malloc/free: duration.count() us std::endl; } void benchmark_pool(MultiSizeMemoryPool pool, size_t block_size, int iterations) { auto start std::chrono::high_resolution_clock::now(); for (int i 0; i iterations; i) { void* p pool.Allocate(block_size); *(static_castchar*(p)) a; pool.Deallocate(p, block_size); } auto end std::chrono::high_resolution_clock::now(); auto duration std::chrono::duration_caststd::chrono::microseconds(end - start); std::cout MemoryPool Alloc/Dealloc: duration.count() us std::endl; }6. 集成到现有项目与进阶优化实现了一个基础版本后你可以将其集成到自己的项目中替换默认的new和delete。最简单的方法是重载全局的operator new和operator delete。// 全局内存池实例 MultiSizeMemoryPool g_memory_pool; void* operator new(std::size_t size) { if (void* ptr g_memory_pool.Allocate(size)) { return ptr; } // 内存池无法分配比如请求过大回退到系统 return std::malloc(size); } void operator delete(void* ptr, std::size_t size) noexcept { if (ptr) { g_memory_pool.Deallocate(ptr, size); } } // 还需要重载不抛出异常的版本以及数组版本进阶优化方向自适应尺寸等级可以根据程序运行时的实际分配大小分布动态调整size_classes_以获得最低的内部碎片率。这需要在池中增加统计功能。垃圾回收与内存返还实现更智能的线程本地缓存收缩策略。当线程空闲内存过多时自动将部分内存块归还给全局池甚至进一步由全局池在空闲时归还给操作系统减少长期的内存占用。调试与统计功能在调试版本中可以在分配的内存块周围添加保护字节canary来检测缓冲区溢出或者记录分配/释放的堆栈信息便于定位内存泄漏。支持非托管内存对于需要与C语言库交互或需要直接传递指针给第三方库的情况确保内存池分配的内存可以用系统的free释放这需要块头来记录信息。考虑缓存行对齐在多核CPU上如果多个线程频繁访问同一个全局数据结构比如全局后备池的某个元数据可能会引发“伪共享”False Sharing。可以将关键数据结构的成员按缓存行通常64字节对齐以减少CPU缓存同步的开销。我个人在实际集成中最深的体会是不要试图用一个内存池解决所有问题。对于非常大的内存分配比如超过一个页面大小如4KB直接使用系统malloc或mmap可能是更好的选择因为池化带来的碎片和管理开销可能超过其收益。因此我的MultiSizeMemoryPool通常会设置一个上限比如4KB超过这个大小的请求直接转发给系统分配器。这种混合策略在实践中最为有效。最后内存池的调试比普通代码更困难因为内存问题具有滞后性。务必在项目早期集成并配合Valgrind、AddressSanitizer等工具进行严格的测试确保每一块分配的内存都有对应的释放并且没有越界访问。一旦内存池本身稳定了它将成为你应用性能最坚实的底座之一。