1. 项目概述Central Cache在高并发内存池中的核心定位在上一篇文章中我们详细拆解了Thread Cache的设计它作为线程专属的内存缓存通过TLS机制实现了线程无锁访问是应对高并发场景下频繁小内存分配的第一道防线。然而Thread Cache并非孤立存在它需要一个“后勤补给中心”来维持自身的平衡与稳定。这个补给中心就是我们今天要深入探讨的Central Cache。你可以把Central Cache想象成一个“内存批发市场”。每个线程的Thread Cache是“零售小店”当小店Thread Cache的某种规格内存块Span库存不足时它不会直接去向系统Page Heap进货因为系统调用如malloc或brk的成本太高尤其是在高并发下频繁的系统调用会成为性能瓶颈。相反它会去“批发市场”Central Cache批量采购。反过来当小店的某种内存块库存过多占用资金内存时它也可以将多余的库存退回给批发市场由市场重新调配给其他缺货的小店。Central Cache的核心价值就在于集中管理从Page Heap申请来的大块内存Span并将其切割成统一规格的小块按需分配给各个Thread Cache同时回收Thread Cache返还的冗余内存实现跨线程的内存平衡与复用。它的设计目标非常明确作为Thread Cache和Page Heap之间的中间层减少线程向系统直接申请内存的次数同时避免某个线程独占过多内存而其他线程饥饿的问题。为了实现这个目标Central Cache面临几个关键挑战首先它必须是一个全局唯一的单例所有线程共享。其次由于会被多个线程并发访问锁的粒度控制至关重要锁得太粗会阻塞所有线程锁得太细又可能过于复杂。最后它需要高效地管理不同大小规格的内存块链表并处理与Thread Cache之间的“申请”与“回收”交互协议。2. Central Cache的整体架构与设计思路拆解Central Cache的架构设计核心是围绕“规格化存储”和“锁粒度细化”两个原则展开的。这与Thread Cache的“线程局部”思路形成了鲜明对比。2.1 核心数据结构Span与SpanList的再进化在Thread Cache中我们管理的是一个个独立的内存块FreeList。但在Central Cache层面我们管理的单元升级了变成了Span。一个Span代表从Page Heap申请来的一大块连续内存其大小是页Page例如4KB或8KB的整数倍。Central Cache并不直接持有零散的内存块而是持有这些Span并根据Span内部的内存块使用情况来组织它们。因此Central Cache的核心数据结构是一个哈希桶与Thread Cache类似桶的个数对应不同的内存大小规格例如8B, 16B, ..., 256KB。但每个桶里挂的不是FreeList而是SpanList——一个双向链表链表中的每个节点都是一个Span对象。// 简化版Span结构定义在Central Cache视角 struct Span { PAGE_ID _pageId; // 起始页号用于后续合并等操作 size_t _n; // 这个Span有多少页 Span* _next; Span* _prev; void* _freeList; // 指向Span内切分好的内存块自由链表链表头 size_t _useCount; // 已被分配给Thread Cache的内存块数量 size_t _objSize; // 该Span切分出的每个内存块的大小 }; class CentralCache { private: SpanList _spanLists[NFREELIST]; // 哈希桶每个桶是一个SpanList static CentralCache _sInst; // 单例对象 // ... 其他成员 };这里的关键在于Span::_freeList和_useCount。当一个Span刚从Page Heap申请来时Central Cache会将其按对应的对象大小_objSize进行切分形成一个由_freeList指向的内存块链表。_useCount则记录了这个Span中有多少块已经被分配出去给了Thread Cache。当_useCount 0时表示整个Span的所有内存块都已归还这个Span就可以被释放回Page Heap。2.2 锁的设计桶锁代替全局锁Central Cache是全局的必然面临并发问题。最粗暴的方法是给整个Central Cache加一把大锁全局锁但这样所有线程在申请/归还内存时都要排队并发性能会急剧下降。高效的设计是采用桶锁Bucket Lock。即为哈希桶数组中的每一个桶SpanList配备一把独立的锁例如std::mutex。当Thread Cache需要申请或归还特定大小的内存时它只需要锁住对应的那个桶即可。这样不同大小规格的内存操作可以完全并行只有操作同一规格内存的线程之间才需要竞争。这极大地提升了并发度。class SpanList { public: // ... 链表操作接口 private: Span* _head; std::mutex _mtx; // 每个SpanList都有自己的锁 };注意在实际实现中选择锁的类型很重要。std::mutex是操作系统级别的互斥锁适用于一般竞争。在极端高并发场景下也可以考虑使用更轻量的自旋锁std::atomic_flag但需谨慎评估CPU空转的代价。我们的设计先以std::mutex为基础。2.3 与Thread Cache的交互协议Central Cache与Thread Cache的交互是双向的且遵循特定的“批量”协议这是平衡性能与内存利用率的关键。Thread Cache申请内存FetchFromCentralCacheThread Cache的某个自由链表为空或不足时会向Central Cache发起申请。它不会一次只申请一个块那样效率太低。而是有一个慢启动的批量申请逻辑初始申请少量如1个随着该规格内存需求持续旺盛下次申请的数量会逐步增加例如24...直至一个上限如512个。这既避免了初次申请就占用过多内存又能适应高频分配需求。Thread Cache调用CentralCache::FetchRangeObj(void* start, void* end, size_t batchNum, size_t size)传入期望的批量数量batchNum和内存块大小size。Central Cache在对应的桶中寻找一个非空的Span从其_freeList中取出至多batchNum个内存块更新Span的_useCount然后将这批内存块的首尾指针start,end返回给Thread Cache。如果Central Cache中该规格的所有Span都为空即没有可分配的内存块则Central Cache会向Page Heap申请一个新的Span一大块内存将其切分后挂入对应桶的SpanList然后再从中分配。Thread Cache归还内存ReleaseListToSpans当Thread Cache的某个自由链表过长超过某个阈值例如一次批量申请的数量为了不浪费内存它会将一部分内存块归还给Central Cache。Thread Cache将一串内存块链表start,end和其大小size传给CentralCache::ReleaseListToSpans(void* start, size_t size)。Central Cache需要根据每个内存块的地址找到它所属的Span。这是一个关键操作通常需要通过页号映射来实现后续与Page Heap联动时会详述。找到对应Span后将内存块头插回该Span的_freeList并递减_useCount。如果某个Span的_useCount减为0说明这个Span的所有内存块都已归还。此时Central Cache不能立即将其释放因为可能还有其他线程正在操作该Span链表。一个常见的优化是将其移动到另一个“待释放”列表或直接释放回Page Heap需要桶锁保护。3. Central Cache核心功能实现细节解析理解了架构我们深入到代码层面看看几个最核心的函数是如何实现的以及其中隐藏的“坑”。3.1 从Central Cache获取内存块FetchRangeObj这是Thread Cache“进货”的入口。其核心逻辑是找到对应大小的桶锁住遍历桶内的Span链表找到一个有剩余内存块_freeList不为空的Span然后进行切割分配。// 从Central Cache获取一段范围的内存块给Thread Cache // start和end是输出参数用于返回获取到的内存块链表的起始和结束 // batchNum是期望获取的个数size是每个内存块的大小 size_t CentralCache::FetchRangeObj(void* start, void* end, size_t batchNum, size_t size) { // 1. 根据size找到对应的哈希桶下标 size_t index SizeClass::Index(size); // 2. 锁住这个桶 _spanLists[index]._mtx.lock(); Span* span GetOneSpan(_spanLists[index], size); if (span nullptr) { _spanLists[index]._mtx.unlock(); return 0; // 理论上GetOneSpan会保证有Span这里防御性判断 } // 3. 从选中的Span中批量获取内存块 void* prev nullptr; void* cur span-_freeList; size_t actualNum 0; for (; actualNum batchNum cur ! nullptr; actualNum) { prev cur; cur NextObj(cur); // NextObj是一个宏或内联函数通过内存头部的指针找到下一个块 } // 4. 调整Span的自由链表和已用计数 start span-_freeList; // 这批块的起点就是原自由链表头 end prev; // 这批块的终点是prev span-_freeList cur; // Span的新链表头是cur可能为空 span-_useCount actualNum; // 分配出去多少块计数就增加多少 // 5. 将获取到的这批内存块从链表中“断开” // 即让end-next nullptr if (end ! nullptr) { NextObj(end) nullptr; } // 6. 解锁并返回实际获取的个数 _spanLists[index]._mtx.unlock(); return actualNum; }关键点与避坑指南锁的范围锁必须在找到并操作完Span之后才能释放。如果在GetOneSpan返回后就解锁其他线程可能同时修改这个Span的_freeList导致数据竞争。GetOneSpan函数这是FetchRangeObj的核心依赖。它的职责是保证返回一个至少有一个空闲块的Span。如果当前桶里所有Span的_freeList都为空它需要向Page Heap申请新Span。这个函数内部也持有桶锁因此需要小心递归锁或锁粒度调整。实际获取数量循环条件actualNum batchNum cur ! nullptr。batchNum是期望值但可能Span里剩余块数不足。因此必须用actualNum记录实际获取的数量并据此更新span-_useCount。Thread Cache需要根据这个返回值来调整自己的自由链表。3.2 为桶获取一个可用的SpanGetOneSpan这个函数是Central Cache内存供给的保障。它遍历指定桶的SpanList寻找第一个非空的Span。如果找不到就向Page Heap“进货”。// 获取一个非空的Span如果桶里没有就向PageHeap申请 Span* CentralCache::GetOneSpan(SpanList list, size_t size) { // 1. 先查看当前桶里是否有非空的Span Span* it list.Begin(); while (it ! list.End()) { if (it-_freeList ! nullptr) { return it; } it it-_next; } // 2. 走到这里说明当前桶里所有Span都空了。需要解锁然后向PageHeap申请。 // 注意这里必须先解锁因为PageHeap::NewSpan()可能涉及系统调用或操作其他全局结构耗时较长。 // 持有当前桶锁去申请会阻塞所有同规格内存的申请线程性能极差。 list._mtx.unlock(); // 3. 向PageHeap申请一个大的Span。申请多少页由SizeClass决定。 size_t npage SizeClass::NumMovePage(size); Span* newSpan PageHeap::GetInstance()-NewSpan(npage); if (newSpan nullptr) { // 申请失败通常意味着系统内存不足。这里可以重新加锁并返回nullptr或者抛异常。 list._mtx.lock(); return nullptr; } // 4. 将申请到的大块内存newSpan切分成size大小的小块并连接成自由链表 // 计算起始地址和结束地址 char* start (char*)(newSpan-_pageId PAGE_SHIFT); // 页号转地址 char* end start (npage PAGE_SHIFT); // 起始地址 总字节数 // 先切成一块块 void* cur nullptr; void* prev nullptr; // 遍历切分采用头插法构建链表头插法更简单高效 for (char* obj start; obj size end; obj size) { prev cur; cur obj; NextObj(cur) prev; // 将当前块的next指向上一块 } newSpan-_freeList cur; // 链表头是最后切分的那块 newSpan-_useCount 0; // 初始时一块都还没分配出去 newSpan-_objSize size; // 记录这个Span切分的块大小 // 5. 将切分好的newSpan插入到桶的SpanList中。注意这里需要重新加锁 list._mtx.lock(); list.PushFront(newSpan); // 6. 返回这个新的Span此时它的_freeList非空 return newSpan; }这是整个Central Cache最易出错的地方之一解锁的时机在遍历完桶发现没有可用Span后必须先解锁list._mtx再去调用PageHeap::NewSpan。因为NewSpan可能很慢涉及系统调用或复杂逻辑长时间持有桶锁是灾难性的。这体现了锁粒度控制的重要性。重新加锁的时机从PageHeap拿到新的Span并完成切分后在将其插入桶的链表之前必须重新加上桶锁。因为插入操作修改了共享的链表结构必须受锁保护。链表构建切分内存构建自由链表时头插法是最简单的。注意计算好每个块的起始地址并正确设置每个内存块头部的next指针通常是在每个内存块起始处存储一个void*。Span信息记录务必正确设置_freeList、_useCount和_objSize。_useCount从0开始因为此时还没有块被分配出去。3.3 将内存块链表归还给Central CacheReleaseListToSpans这是Thread Cache“退货”的入口。其核心挑战是给定一串内存块链表和它们的大小如何高效地将每个块归还到其所属的Span中// 将Thread Cache归还的一串内存块链表释放回Central Cache对应的Span中 void CentralCache::ReleaseListToSpans(void* start, size_t size) { // 1. 根据size找到对应的桶 size_t index SizeClass::Index(size); SpanList list _spanLists[index]; // 2. 遍历归还的链表将每个块插入对应Span的自由链表 void* cur start; while (cur) { void* next NextObj(cur); // 先保存下一个块因为插入后cur的next会被修改 // 3. 关键步骤根据内存块地址cur找到它属于哪个Span Span* span PageHeap::GetInstance()-MapObjectToSpan(cur); assert(span ! nullptr); // 理论上应该总能找到 // 4. 将当前块头插到span的自由链表中 // 注意此操作需要桶锁保护因为多个线程可能同时归还内存到同一个桶甚至同一个Span list._mtx.lock(); NextObj(cur) span-_freeList; span-_freeList cur; span-_useCount--; // 归还一块计数减一 // 5. 检查如果span的_useCount减为0说明所有块都已归还。 // 此时可以将整个Span释放回PageHeap避免Central Cache占用过多空闲内存。 if (span-_useCount 0) { // 先将该Span从桶的链表中摘除 list.Erase(span); // 解锁因为ReleaseSpanToPageHeap可能涉及其他锁或耗时操作。 list._mtx.unlock(); // 释放Span回PageHeap PageHeap::GetInstance()-ReleaseSpanToPageHeap(span); // 注意这里不需要重新加锁因为当前Span已经不属于这个桶了。 } else { list._mtx.unlock(); } cur next; // 处理下一个块 } }实现难点与优化点地址到Span的映射MapObjectToSpan这是整个内存池的基石之一。给定一个任意内存块的地址如何快速找到它所属的Span通常的解决方案是页映射表。在Page Heap申请Span时会记录这个Span覆盖了哪些页_pageId到_pageId_n。我们可以建立一个全局的数组std::vectorSpan*或Span* []数组下标是页号PAGE_ID数组元素是该页所属的Span指针。这样对于任何内存地址右移PAGE_SHIFT位得到页号再用页号作为下标去查表就能立刻找到其所属的Span。这个表由Page Heap负责维护。锁的粒度注意我们在循环内对每个块处理时都进行了加锁和解锁。这是因为span-_useCount--和修改_freeList是临界区。如果我们在循环外加锁就会长时间持有锁阻塞其他线程。在循环内加锁锁的粒度更细并发度更高。但这也带来了频繁加解锁的开销。一种折衷是可以先遍历链表将属于同一个Span的块分组然后以Span为单位进行加锁和批量插入减少锁操作次数。Span的释放时机当_useCount 0时意味着这个Span完全空闲。此时将其释放回PageHeap是合理的可以防止Central Cache囤积过多空闲内存。释放前需要将其从桶链表中移除Erase。特别注意在调用ReleaseSpanToPageHeap之前必须先解锁桶锁理由同GetOneSpan中调用NewSpan一样。断言的使用assert(span ! nullptr)是一个强有力的调试保障。如果这里找到空指针说明地址映射出现了严重错误如内存越界、重复释放等应立即终止程序以便排查。4. 性能关键锁竞争优化与无锁化探索Central Cache作为共享资源锁竞争是其性能瓶颈的主要来源。我们采用了桶锁这已经比全局锁好很多。但还有进一步优化的空间。4.1 细粒度锁的代价与收益我们当前的实现是“每个操作获取/归还一个块都可能加解锁一次”。在极端高并发下这仍然可能成为热点。性能测试时可以用perf工具观察_mtx.lock()的CPU周期占比。优化思路一批量操作合并锁在ReleaseListToSpans中我们可以先不加锁遍历一次归还链表用一个std::unordered_mapSpan*, std::vectorvoid*将块按Span分组。然后遍历这个map对每个Span加锁一次性将其所有块头插到该Span的自由链表中并更新_useCount。这样锁的次数从O(N)N为块数降到了O(M)M为涉及的Span数。通常M远小于N。优化思路二使用更轻量的锁std::mutex是通用互斥锁。对于临界区极短只是修改几个指针和计数器的场景可以考虑使用自旋锁std::atomic_flag。自旋锁在获取不到锁时会忙等待循环检查避免了线程切换的开销但会浪费CPU。适用于锁持有时间非常短纳秒/微秒级且竞争不特别激烈的场景。实现时需要仔细测试。class SpinLock { std::atomic_flag flag ATOMIC_FLAG_INIT; public: void lock() { while (flag.test_and_set(std::memory_order_acquire)); } void unlock() { flag.clear(std::memory_order_release); } }; // 然后将SpanList中的std::mutex替换为SpinLock。4.2 无锁链表的可能性高级话题对于追求极致性能的场景可以探索无锁Lock-Free数据结构。例如实现一个无锁的SpanList或无锁的每个Span内部的_freeList。这通常使用std::atomic和compare_exchange_weak/strongCAS操作来实现。例如一个无锁栈可用于实现自由链表的push操作可能像这样void push(Node* new_node) { new_node-next head.load(std::memory_order_relaxed); while (!head.compare_exchange_weak(new_node-next, new_node, std::memory_order_release, std::memory_order_relaxed)); }但是无锁编程极其复杂需要处理ABA问题、内存序memory order等容易引入难以调试的bug。对于大多数项目经过良好优化的细粒度互斥锁桶锁自旋锁已经能提供非常出色的性能并且代码可读性和可维护性远高于无锁实现。除非性能分析明确表明锁竞争是主要瓶颈否则不建议轻易引入无锁编程。5. 与Page Heap的联动及边界条件处理Central Cache并不直接与系统内存打交道它通过Page Heap这个“仓库管理员”来申请和释放大块内存Span。因此两者的接口设计和协作至关重要。5.1 申请SpanNewSpan的协作当Central Cache的某个桶没有可用Span时GetOneSpan会调用PageHeap::NewSpan(npage)。npage是需要的页数由SizeClass::NumMovePage(size)计算得出。这个计算需要权衡一次申请太多页可能造成浪费申请太少又会频繁调用Page Heap。一个常见的策略是根据要切分的内存块大小size计算出一个能切分出大约batchNumMax例如128或512个块的页数并向上对齐到页的整数倍。这样一次申请就能满足Thread Cache很多次的批量请求。5.2 释放SpanReleaseSpanToPageHeap的协作当Central Cache发现一个Span完全空闲_useCount 0时就调用PageHeap::ReleaseSpanToPageHeap(span)将其归还。Page Heap收到这个Span后会尝试与它前后相邻的空闲Span进行合并形成更大的空闲Span以减少内存碎片。这里有一个关键点Central Cache在释放Span前必须确保没有线程再持有指向该Span内任何内存块的指针。在我们的设计中这是由_useCount计数器保证的。当_useCount为0时所有从该Span分配出去的内存块都已归还。但这里存在一个非常隐蔽的并发问题考虑以下时序线程A执行ReleaseListToSpans发现某个Span的_useCount从1减为0准备释放。在线程A调用list.Erase(span)之后list._mtx.unlock()之前线程B正在遍历这个桶的链表例如在GetOneSpan中它可能刚好看过这个Span但还没读取其_freeList。线程A解锁然后调用ReleaseSpanToPageHeapPage Heap可能会立即将这个Span合并甚至归还给操作系统。线程B随后尝试访问这个Span的_freeList就会导致访问已释放内存程序崩溃。解决方案确保_useCount的检查和归零操作、Span从链表中的移除、以及后续释放操作在一个连续的、受锁保护的临界区内完成并且在这个临界区内其他线程无法访问到这个Span。在我们的代码中list.Erase(span)将其从链表移除后其他线程通过链表遍历就找不到它了即使锁暂时释放它们也无法获得其指针。但更安全的做法是将ReleaseSpanToPageHeap的调用也放在桶锁的保护下或者使用引用计数等更安全的内存回收机制。对于学习项目在锁内释放是更简单安全的选择但要注意ReleaseSpanToPageHeap内部不能再去尝试获取同一个桶锁否则会导致死锁。5.3 内存碎片与合并策略的间接影响Central Cache虽然不直接处理碎片但其行为会影响碎片。如果Central Cache过快地将空闲Span释放回Page Heap可能导致Thread Cache频繁地重新申请增加系统调用。如果持有过久又会导致内存利用率下降。因此可以引入一个简单的缓存策略即使_useCount 0也不立即释放而是将其标记为空闲保留在Central Cache的链表中一段时间或直到需要内存时再释放。这相当于在Central Cache层面做了一个小型的空闲Span缓存。6. 测试、调试与性能分析实战实现完Central Cache后必须进行 rigorous 的测试。6.1 单元测试设计单线程基础功能测试测试FetchRangeObj申请不同大小的内存检查返回的链表是否正确Span的_useCount是否更新。测试ReleaseListToSpans构造一个内存块链表归还检查是否正确地插回了对应Span_useCount是否减少Span释放逻辑是否正确触发。测试GetOneSpan模拟桶为空的情况验证其能正确从Page Heap申请并切分新Span。多线程并发正确性测试压力测试创建多个线程每个线程随机进行大量次数的申请和释放大小随机或固定。运行一段时间后检查是否有内存泄漏最终所有内存应能全部归还。是否有双倍释放通过地址映射表断言检查。程序是否崩溃数据竞争导致。特定场景测试一个线程不断申请另一个线程不断归还同一规格内存。多个线程同时申请和归还不同规格的内存测试桶锁的隔离性。工具辅助使用ThreadSanitizer (TSan)来检测数据竞争。在GCC/Clang编译时添加-fsanitizethread选项。6.2 性能分析Profiling使用性能分析工具如gperftools的 CPU Profiler或perf来观察热点函数时间主要消耗在FetchRangeObj、ReleaseListToSpans还是锁操作上锁竞争_mtx.lock()的等待时间是否很长如果是说明该桶是热点可能需要进一步细分锁粒度但规格已经是最细了或者考虑无锁优化。系统调用PageHeap::NewSpan被调用的频率是否过高这反映了Central Cache的缓存效果。可以通过调整SizeClass::NumMovePage的逻辑来优化。6.3 常见问题排查实录程序随机崩溃尤其在多线程环境下首先怀疑数据竞争检查所有对SpanList、Span成员尤其是_freeList,_useCount,_next,_prev的访问是否都在锁的保护之下。使用ThreadSanitizer验证。检查地址映射表在MapObjectToSpan中增加断言和日志确保任何归还的内存地址都能找到有效的Span。找不到通常意味着内存越界或重复释放了不属于内存池的内存。检查链表操作在Erase、PushFront等链表操作前后检查链表节点的_next和_prev指针是否被意外修改。内存泄漏在程序结束时遍历Central Cache所有桶的所有Span检查是否还有_useCount 0的Span。如果有说明有内存块没有归还。更全面的方法是实现一个CentralCache::PrintLeaks()函数打印出所有未释放的Span信息页号、大小、未归还块数。性能不如预期锁竞争使用perf查看锁的contention。如果某个桶的锁竞争激烈可以考虑是否该规格的内存分配过于频繁是否需要调整Thread Cache的慢启动批量数量或者引入更高效的锁。Span频繁申请/释放如果PageHeap::NewSpan调用频繁说明Central Cache的缓存命中率低。可以尝试让Central Cache保留一些完全空闲的Span延迟释放或者调整NumMovePage让一次申请的Span更大。遍历开销在GetOneSpan中需要遍历SpanList寻找非空Span。如果链表很长遍历开销大。可以考虑维护两个链表非空Span链表和空Span链表快速定位。Central Cache作为高并发内存池的“中枢神经”其稳定性和性能直接决定了整个内存池的上限。它巧妙地在共享与隔离、速度与空间之间取得了平衡。理解其每一行代码背后的并发考量、数据结构设计和边界处理是掌握高并发编程和内存管理精髓的绝佳途径。在实现过程中多写测试多用工具分析遇到诡异问题时首先怀疑并发安全这样才能构建出既快又稳的内存池中间层。
高并发内存池Central Cache：设计原理、锁优化与工程实践
1. 项目概述Central Cache在高并发内存池中的核心定位在上一篇文章中我们详细拆解了Thread Cache的设计它作为线程专属的内存缓存通过TLS机制实现了线程无锁访问是应对高并发场景下频繁小内存分配的第一道防线。然而Thread Cache并非孤立存在它需要一个“后勤补给中心”来维持自身的平衡与稳定。这个补给中心就是我们今天要深入探讨的Central Cache。你可以把Central Cache想象成一个“内存批发市场”。每个线程的Thread Cache是“零售小店”当小店Thread Cache的某种规格内存块Span库存不足时它不会直接去向系统Page Heap进货因为系统调用如malloc或brk的成本太高尤其是在高并发下频繁的系统调用会成为性能瓶颈。相反它会去“批发市场”Central Cache批量采购。反过来当小店的某种内存块库存过多占用资金内存时它也可以将多余的库存退回给批发市场由市场重新调配给其他缺货的小店。Central Cache的核心价值就在于集中管理从Page Heap申请来的大块内存Span并将其切割成统一规格的小块按需分配给各个Thread Cache同时回收Thread Cache返还的冗余内存实现跨线程的内存平衡与复用。它的设计目标非常明确作为Thread Cache和Page Heap之间的中间层减少线程向系统直接申请内存的次数同时避免某个线程独占过多内存而其他线程饥饿的问题。为了实现这个目标Central Cache面临几个关键挑战首先它必须是一个全局唯一的单例所有线程共享。其次由于会被多个线程并发访问锁的粒度控制至关重要锁得太粗会阻塞所有线程锁得太细又可能过于复杂。最后它需要高效地管理不同大小规格的内存块链表并处理与Thread Cache之间的“申请”与“回收”交互协议。2. Central Cache的整体架构与设计思路拆解Central Cache的架构设计核心是围绕“规格化存储”和“锁粒度细化”两个原则展开的。这与Thread Cache的“线程局部”思路形成了鲜明对比。2.1 核心数据结构Span与SpanList的再进化在Thread Cache中我们管理的是一个个独立的内存块FreeList。但在Central Cache层面我们管理的单元升级了变成了Span。一个Span代表从Page Heap申请来的一大块连续内存其大小是页Page例如4KB或8KB的整数倍。Central Cache并不直接持有零散的内存块而是持有这些Span并根据Span内部的内存块使用情况来组织它们。因此Central Cache的核心数据结构是一个哈希桶与Thread Cache类似桶的个数对应不同的内存大小规格例如8B, 16B, ..., 256KB。但每个桶里挂的不是FreeList而是SpanList——一个双向链表链表中的每个节点都是一个Span对象。// 简化版Span结构定义在Central Cache视角 struct Span { PAGE_ID _pageId; // 起始页号用于后续合并等操作 size_t _n; // 这个Span有多少页 Span* _next; Span* _prev; void* _freeList; // 指向Span内切分好的内存块自由链表链表头 size_t _useCount; // 已被分配给Thread Cache的内存块数量 size_t _objSize; // 该Span切分出的每个内存块的大小 }; class CentralCache { private: SpanList _spanLists[NFREELIST]; // 哈希桶每个桶是一个SpanList static CentralCache _sInst; // 单例对象 // ... 其他成员 };这里的关键在于Span::_freeList和_useCount。当一个Span刚从Page Heap申请来时Central Cache会将其按对应的对象大小_objSize进行切分形成一个由_freeList指向的内存块链表。_useCount则记录了这个Span中有多少块已经被分配出去给了Thread Cache。当_useCount 0时表示整个Span的所有内存块都已归还这个Span就可以被释放回Page Heap。2.2 锁的设计桶锁代替全局锁Central Cache是全局的必然面临并发问题。最粗暴的方法是给整个Central Cache加一把大锁全局锁但这样所有线程在申请/归还内存时都要排队并发性能会急剧下降。高效的设计是采用桶锁Bucket Lock。即为哈希桶数组中的每一个桶SpanList配备一把独立的锁例如std::mutex。当Thread Cache需要申请或归还特定大小的内存时它只需要锁住对应的那个桶即可。这样不同大小规格的内存操作可以完全并行只有操作同一规格内存的线程之间才需要竞争。这极大地提升了并发度。class SpanList { public: // ... 链表操作接口 private: Span* _head; std::mutex _mtx; // 每个SpanList都有自己的锁 };注意在实际实现中选择锁的类型很重要。std::mutex是操作系统级别的互斥锁适用于一般竞争。在极端高并发场景下也可以考虑使用更轻量的自旋锁std::atomic_flag但需谨慎评估CPU空转的代价。我们的设计先以std::mutex为基础。2.3 与Thread Cache的交互协议Central Cache与Thread Cache的交互是双向的且遵循特定的“批量”协议这是平衡性能与内存利用率的关键。Thread Cache申请内存FetchFromCentralCacheThread Cache的某个自由链表为空或不足时会向Central Cache发起申请。它不会一次只申请一个块那样效率太低。而是有一个慢启动的批量申请逻辑初始申请少量如1个随着该规格内存需求持续旺盛下次申请的数量会逐步增加例如24...直至一个上限如512个。这既避免了初次申请就占用过多内存又能适应高频分配需求。Thread Cache调用CentralCache::FetchRangeObj(void* start, void* end, size_t batchNum, size_t size)传入期望的批量数量batchNum和内存块大小size。Central Cache在对应的桶中寻找一个非空的Span从其_freeList中取出至多batchNum个内存块更新Span的_useCount然后将这批内存块的首尾指针start,end返回给Thread Cache。如果Central Cache中该规格的所有Span都为空即没有可分配的内存块则Central Cache会向Page Heap申请一个新的Span一大块内存将其切分后挂入对应桶的SpanList然后再从中分配。Thread Cache归还内存ReleaseListToSpans当Thread Cache的某个自由链表过长超过某个阈值例如一次批量申请的数量为了不浪费内存它会将一部分内存块归还给Central Cache。Thread Cache将一串内存块链表start,end和其大小size传给CentralCache::ReleaseListToSpans(void* start, size_t size)。Central Cache需要根据每个内存块的地址找到它所属的Span。这是一个关键操作通常需要通过页号映射来实现后续与Page Heap联动时会详述。找到对应Span后将内存块头插回该Span的_freeList并递减_useCount。如果某个Span的_useCount减为0说明这个Span的所有内存块都已归还。此时Central Cache不能立即将其释放因为可能还有其他线程正在操作该Span链表。一个常见的优化是将其移动到另一个“待释放”列表或直接释放回Page Heap需要桶锁保护。3. Central Cache核心功能实现细节解析理解了架构我们深入到代码层面看看几个最核心的函数是如何实现的以及其中隐藏的“坑”。3.1 从Central Cache获取内存块FetchRangeObj这是Thread Cache“进货”的入口。其核心逻辑是找到对应大小的桶锁住遍历桶内的Span链表找到一个有剩余内存块_freeList不为空的Span然后进行切割分配。// 从Central Cache获取一段范围的内存块给Thread Cache // start和end是输出参数用于返回获取到的内存块链表的起始和结束 // batchNum是期望获取的个数size是每个内存块的大小 size_t CentralCache::FetchRangeObj(void* start, void* end, size_t batchNum, size_t size) { // 1. 根据size找到对应的哈希桶下标 size_t index SizeClass::Index(size); // 2. 锁住这个桶 _spanLists[index]._mtx.lock(); Span* span GetOneSpan(_spanLists[index], size); if (span nullptr) { _spanLists[index]._mtx.unlock(); return 0; // 理论上GetOneSpan会保证有Span这里防御性判断 } // 3. 从选中的Span中批量获取内存块 void* prev nullptr; void* cur span-_freeList; size_t actualNum 0; for (; actualNum batchNum cur ! nullptr; actualNum) { prev cur; cur NextObj(cur); // NextObj是一个宏或内联函数通过内存头部的指针找到下一个块 } // 4. 调整Span的自由链表和已用计数 start span-_freeList; // 这批块的起点就是原自由链表头 end prev; // 这批块的终点是prev span-_freeList cur; // Span的新链表头是cur可能为空 span-_useCount actualNum; // 分配出去多少块计数就增加多少 // 5. 将获取到的这批内存块从链表中“断开” // 即让end-next nullptr if (end ! nullptr) { NextObj(end) nullptr; } // 6. 解锁并返回实际获取的个数 _spanLists[index]._mtx.unlock(); return actualNum; }关键点与避坑指南锁的范围锁必须在找到并操作完Span之后才能释放。如果在GetOneSpan返回后就解锁其他线程可能同时修改这个Span的_freeList导致数据竞争。GetOneSpan函数这是FetchRangeObj的核心依赖。它的职责是保证返回一个至少有一个空闲块的Span。如果当前桶里所有Span的_freeList都为空它需要向Page Heap申请新Span。这个函数内部也持有桶锁因此需要小心递归锁或锁粒度调整。实际获取数量循环条件actualNum batchNum cur ! nullptr。batchNum是期望值但可能Span里剩余块数不足。因此必须用actualNum记录实际获取的数量并据此更新span-_useCount。Thread Cache需要根据这个返回值来调整自己的自由链表。3.2 为桶获取一个可用的SpanGetOneSpan这个函数是Central Cache内存供给的保障。它遍历指定桶的SpanList寻找第一个非空的Span。如果找不到就向Page Heap“进货”。// 获取一个非空的Span如果桶里没有就向PageHeap申请 Span* CentralCache::GetOneSpan(SpanList list, size_t size) { // 1. 先查看当前桶里是否有非空的Span Span* it list.Begin(); while (it ! list.End()) { if (it-_freeList ! nullptr) { return it; } it it-_next; } // 2. 走到这里说明当前桶里所有Span都空了。需要解锁然后向PageHeap申请。 // 注意这里必须先解锁因为PageHeap::NewSpan()可能涉及系统调用或操作其他全局结构耗时较长。 // 持有当前桶锁去申请会阻塞所有同规格内存的申请线程性能极差。 list._mtx.unlock(); // 3. 向PageHeap申请一个大的Span。申请多少页由SizeClass决定。 size_t npage SizeClass::NumMovePage(size); Span* newSpan PageHeap::GetInstance()-NewSpan(npage); if (newSpan nullptr) { // 申请失败通常意味着系统内存不足。这里可以重新加锁并返回nullptr或者抛异常。 list._mtx.lock(); return nullptr; } // 4. 将申请到的大块内存newSpan切分成size大小的小块并连接成自由链表 // 计算起始地址和结束地址 char* start (char*)(newSpan-_pageId PAGE_SHIFT); // 页号转地址 char* end start (npage PAGE_SHIFT); // 起始地址 总字节数 // 先切成一块块 void* cur nullptr; void* prev nullptr; // 遍历切分采用头插法构建链表头插法更简单高效 for (char* obj start; obj size end; obj size) { prev cur; cur obj; NextObj(cur) prev; // 将当前块的next指向上一块 } newSpan-_freeList cur; // 链表头是最后切分的那块 newSpan-_useCount 0; // 初始时一块都还没分配出去 newSpan-_objSize size; // 记录这个Span切分的块大小 // 5. 将切分好的newSpan插入到桶的SpanList中。注意这里需要重新加锁 list._mtx.lock(); list.PushFront(newSpan); // 6. 返回这个新的Span此时它的_freeList非空 return newSpan; }这是整个Central Cache最易出错的地方之一解锁的时机在遍历完桶发现没有可用Span后必须先解锁list._mtx再去调用PageHeap::NewSpan。因为NewSpan可能很慢涉及系统调用或复杂逻辑长时间持有桶锁是灾难性的。这体现了锁粒度控制的重要性。重新加锁的时机从PageHeap拿到新的Span并完成切分后在将其插入桶的链表之前必须重新加上桶锁。因为插入操作修改了共享的链表结构必须受锁保护。链表构建切分内存构建自由链表时头插法是最简单的。注意计算好每个块的起始地址并正确设置每个内存块头部的next指针通常是在每个内存块起始处存储一个void*。Span信息记录务必正确设置_freeList、_useCount和_objSize。_useCount从0开始因为此时还没有块被分配出去。3.3 将内存块链表归还给Central CacheReleaseListToSpans这是Thread Cache“退货”的入口。其核心挑战是给定一串内存块链表和它们的大小如何高效地将每个块归还到其所属的Span中// 将Thread Cache归还的一串内存块链表释放回Central Cache对应的Span中 void CentralCache::ReleaseListToSpans(void* start, size_t size) { // 1. 根据size找到对应的桶 size_t index SizeClass::Index(size); SpanList list _spanLists[index]; // 2. 遍历归还的链表将每个块插入对应Span的自由链表 void* cur start; while (cur) { void* next NextObj(cur); // 先保存下一个块因为插入后cur的next会被修改 // 3. 关键步骤根据内存块地址cur找到它属于哪个Span Span* span PageHeap::GetInstance()-MapObjectToSpan(cur); assert(span ! nullptr); // 理论上应该总能找到 // 4. 将当前块头插到span的自由链表中 // 注意此操作需要桶锁保护因为多个线程可能同时归还内存到同一个桶甚至同一个Span list._mtx.lock(); NextObj(cur) span-_freeList; span-_freeList cur; span-_useCount--; // 归还一块计数减一 // 5. 检查如果span的_useCount减为0说明所有块都已归还。 // 此时可以将整个Span释放回PageHeap避免Central Cache占用过多空闲内存。 if (span-_useCount 0) { // 先将该Span从桶的链表中摘除 list.Erase(span); // 解锁因为ReleaseSpanToPageHeap可能涉及其他锁或耗时操作。 list._mtx.unlock(); // 释放Span回PageHeap PageHeap::GetInstance()-ReleaseSpanToPageHeap(span); // 注意这里不需要重新加锁因为当前Span已经不属于这个桶了。 } else { list._mtx.unlock(); } cur next; // 处理下一个块 } }实现难点与优化点地址到Span的映射MapObjectToSpan这是整个内存池的基石之一。给定一个任意内存块的地址如何快速找到它所属的Span通常的解决方案是页映射表。在Page Heap申请Span时会记录这个Span覆盖了哪些页_pageId到_pageId_n。我们可以建立一个全局的数组std::vectorSpan*或Span* []数组下标是页号PAGE_ID数组元素是该页所属的Span指针。这样对于任何内存地址右移PAGE_SHIFT位得到页号再用页号作为下标去查表就能立刻找到其所属的Span。这个表由Page Heap负责维护。锁的粒度注意我们在循环内对每个块处理时都进行了加锁和解锁。这是因为span-_useCount--和修改_freeList是临界区。如果我们在循环外加锁就会长时间持有锁阻塞其他线程。在循环内加锁锁的粒度更细并发度更高。但这也带来了频繁加解锁的开销。一种折衷是可以先遍历链表将属于同一个Span的块分组然后以Span为单位进行加锁和批量插入减少锁操作次数。Span的释放时机当_useCount 0时意味着这个Span完全空闲。此时将其释放回PageHeap是合理的可以防止Central Cache囤积过多空闲内存。释放前需要将其从桶链表中移除Erase。特别注意在调用ReleaseSpanToPageHeap之前必须先解锁桶锁理由同GetOneSpan中调用NewSpan一样。断言的使用assert(span ! nullptr)是一个强有力的调试保障。如果这里找到空指针说明地址映射出现了严重错误如内存越界、重复释放等应立即终止程序以便排查。4. 性能关键锁竞争优化与无锁化探索Central Cache作为共享资源锁竞争是其性能瓶颈的主要来源。我们采用了桶锁这已经比全局锁好很多。但还有进一步优化的空间。4.1 细粒度锁的代价与收益我们当前的实现是“每个操作获取/归还一个块都可能加解锁一次”。在极端高并发下这仍然可能成为热点。性能测试时可以用perf工具观察_mtx.lock()的CPU周期占比。优化思路一批量操作合并锁在ReleaseListToSpans中我们可以先不加锁遍历一次归还链表用一个std::unordered_mapSpan*, std::vectorvoid*将块按Span分组。然后遍历这个map对每个Span加锁一次性将其所有块头插到该Span的自由链表中并更新_useCount。这样锁的次数从O(N)N为块数降到了O(M)M为涉及的Span数。通常M远小于N。优化思路二使用更轻量的锁std::mutex是通用互斥锁。对于临界区极短只是修改几个指针和计数器的场景可以考虑使用自旋锁std::atomic_flag。自旋锁在获取不到锁时会忙等待循环检查避免了线程切换的开销但会浪费CPU。适用于锁持有时间非常短纳秒/微秒级且竞争不特别激烈的场景。实现时需要仔细测试。class SpinLock { std::atomic_flag flag ATOMIC_FLAG_INIT; public: void lock() { while (flag.test_and_set(std::memory_order_acquire)); } void unlock() { flag.clear(std::memory_order_release); } }; // 然后将SpanList中的std::mutex替换为SpinLock。4.2 无锁链表的可能性高级话题对于追求极致性能的场景可以探索无锁Lock-Free数据结构。例如实现一个无锁的SpanList或无锁的每个Span内部的_freeList。这通常使用std::atomic和compare_exchange_weak/strongCAS操作来实现。例如一个无锁栈可用于实现自由链表的push操作可能像这样void push(Node* new_node) { new_node-next head.load(std::memory_order_relaxed); while (!head.compare_exchange_weak(new_node-next, new_node, std::memory_order_release, std::memory_order_relaxed)); }但是无锁编程极其复杂需要处理ABA问题、内存序memory order等容易引入难以调试的bug。对于大多数项目经过良好优化的细粒度互斥锁桶锁自旋锁已经能提供非常出色的性能并且代码可读性和可维护性远高于无锁实现。除非性能分析明确表明锁竞争是主要瓶颈否则不建议轻易引入无锁编程。5. 与Page Heap的联动及边界条件处理Central Cache并不直接与系统内存打交道它通过Page Heap这个“仓库管理员”来申请和释放大块内存Span。因此两者的接口设计和协作至关重要。5.1 申请SpanNewSpan的协作当Central Cache的某个桶没有可用Span时GetOneSpan会调用PageHeap::NewSpan(npage)。npage是需要的页数由SizeClass::NumMovePage(size)计算得出。这个计算需要权衡一次申请太多页可能造成浪费申请太少又会频繁调用Page Heap。一个常见的策略是根据要切分的内存块大小size计算出一个能切分出大约batchNumMax例如128或512个块的页数并向上对齐到页的整数倍。这样一次申请就能满足Thread Cache很多次的批量请求。5.2 释放SpanReleaseSpanToPageHeap的协作当Central Cache发现一个Span完全空闲_useCount 0时就调用PageHeap::ReleaseSpanToPageHeap(span)将其归还。Page Heap收到这个Span后会尝试与它前后相邻的空闲Span进行合并形成更大的空闲Span以减少内存碎片。这里有一个关键点Central Cache在释放Span前必须确保没有线程再持有指向该Span内任何内存块的指针。在我们的设计中这是由_useCount计数器保证的。当_useCount为0时所有从该Span分配出去的内存块都已归还。但这里存在一个非常隐蔽的并发问题考虑以下时序线程A执行ReleaseListToSpans发现某个Span的_useCount从1减为0准备释放。在线程A调用list.Erase(span)之后list._mtx.unlock()之前线程B正在遍历这个桶的链表例如在GetOneSpan中它可能刚好看过这个Span但还没读取其_freeList。线程A解锁然后调用ReleaseSpanToPageHeapPage Heap可能会立即将这个Span合并甚至归还给操作系统。线程B随后尝试访问这个Span的_freeList就会导致访问已释放内存程序崩溃。解决方案确保_useCount的检查和归零操作、Span从链表中的移除、以及后续释放操作在一个连续的、受锁保护的临界区内完成并且在这个临界区内其他线程无法访问到这个Span。在我们的代码中list.Erase(span)将其从链表移除后其他线程通过链表遍历就找不到它了即使锁暂时释放它们也无法获得其指针。但更安全的做法是将ReleaseSpanToPageHeap的调用也放在桶锁的保护下或者使用引用计数等更安全的内存回收机制。对于学习项目在锁内释放是更简单安全的选择但要注意ReleaseSpanToPageHeap内部不能再去尝试获取同一个桶锁否则会导致死锁。5.3 内存碎片与合并策略的间接影响Central Cache虽然不直接处理碎片但其行为会影响碎片。如果Central Cache过快地将空闲Span释放回Page Heap可能导致Thread Cache频繁地重新申请增加系统调用。如果持有过久又会导致内存利用率下降。因此可以引入一个简单的缓存策略即使_useCount 0也不立即释放而是将其标记为空闲保留在Central Cache的链表中一段时间或直到需要内存时再释放。这相当于在Central Cache层面做了一个小型的空闲Span缓存。6. 测试、调试与性能分析实战实现完Central Cache后必须进行 rigorous 的测试。6.1 单元测试设计单线程基础功能测试测试FetchRangeObj申请不同大小的内存检查返回的链表是否正确Span的_useCount是否更新。测试ReleaseListToSpans构造一个内存块链表归还检查是否正确地插回了对应Span_useCount是否减少Span释放逻辑是否正确触发。测试GetOneSpan模拟桶为空的情况验证其能正确从Page Heap申请并切分新Span。多线程并发正确性测试压力测试创建多个线程每个线程随机进行大量次数的申请和释放大小随机或固定。运行一段时间后检查是否有内存泄漏最终所有内存应能全部归还。是否有双倍释放通过地址映射表断言检查。程序是否崩溃数据竞争导致。特定场景测试一个线程不断申请另一个线程不断归还同一规格内存。多个线程同时申请和归还不同规格的内存测试桶锁的隔离性。工具辅助使用ThreadSanitizer (TSan)来检测数据竞争。在GCC/Clang编译时添加-fsanitizethread选项。6.2 性能分析Profiling使用性能分析工具如gperftools的 CPU Profiler或perf来观察热点函数时间主要消耗在FetchRangeObj、ReleaseListToSpans还是锁操作上锁竞争_mtx.lock()的等待时间是否很长如果是说明该桶是热点可能需要进一步细分锁粒度但规格已经是最细了或者考虑无锁优化。系统调用PageHeap::NewSpan被调用的频率是否过高这反映了Central Cache的缓存效果。可以通过调整SizeClass::NumMovePage的逻辑来优化。6.3 常见问题排查实录程序随机崩溃尤其在多线程环境下首先怀疑数据竞争检查所有对SpanList、Span成员尤其是_freeList,_useCount,_next,_prev的访问是否都在锁的保护之下。使用ThreadSanitizer验证。检查地址映射表在MapObjectToSpan中增加断言和日志确保任何归还的内存地址都能找到有效的Span。找不到通常意味着内存越界或重复释放了不属于内存池的内存。检查链表操作在Erase、PushFront等链表操作前后检查链表节点的_next和_prev指针是否被意外修改。内存泄漏在程序结束时遍历Central Cache所有桶的所有Span检查是否还有_useCount 0的Span。如果有说明有内存块没有归还。更全面的方法是实现一个CentralCache::PrintLeaks()函数打印出所有未释放的Span信息页号、大小、未归还块数。性能不如预期锁竞争使用perf查看锁的contention。如果某个桶的锁竞争激烈可以考虑是否该规格的内存分配过于频繁是否需要调整Thread Cache的慢启动批量数量或者引入更高效的锁。Span频繁申请/释放如果PageHeap::NewSpan调用频繁说明Central Cache的缓存命中率低。可以尝试让Central Cache保留一些完全空闲的Span延迟释放或者调整NumMovePage让一次申请的Span更大。遍历开销在GetOneSpan中需要遍历SpanList寻找非空Span。如果链表很长遍历开销大。可以考虑维护两个链表非空Span链表和空Span链表快速定位。Central Cache作为高并发内存池的“中枢神经”其稳定性和性能直接决定了整个内存池的上限。它巧妙地在共享与隔离、速度与空间之间取得了平衡。理解其每一行代码背后的并发考量、数据结构设计和边界处理是掌握高并发编程和内存管理精髓的绝佳途径。在实现过程中多写测试多用工具分析遇到诡异问题时首先怀疑并发安全这样才能构建出既快又稳的内存池中间层。
