这是一篇接着上回的硬核内容。前两篇聊完了整体框架和第一版能跑通的代码这篇把真正让内存池在高并发下站住脚的那些细节摊开讲锁是怎么拆的、线程缓存怎么做到无锁分配、回收路径上有哪些隐蔽的坑、以及实测数据到底怎么解读。代码我尽量给关键片段不是贴完整源码核心是让你看完能自己上手调知道每行代码在为什么服务。1. 先想明白高并发内存池到底在解决什么问题先说结论在高并发场景下传统内存分配器的性能瓶颈几乎都出在锁和系统调用上。malloc/free内部为了线程安全必须维护全局状态每次分配都可能碰到锁竞争线程越多、分配越频繁这个锁就越热闹。再加上分配大块内存时可能需要经过内核用户态到内核态的切换成本更不低。高并发内存池的思路就是用“空间换时间”把内存管理的粒度拆细让每个线程在绝大多数情况下走自己的私有通道不碰任何公共资源只有本地不够了才去公共区域“进货”。用个生活化的比喻如果每个顾客买瓶水都要去总仓库取仓库门口一定排长队。高并发内存池的做法是每个收银台自己配一个小货架货架上有货就直接拿没货了才派一个人去总仓库补货。不同收银台之间互不干扰总仓库的压力就小很多。具体到这套池子的结构业界经典的方案就是三层架构线程缓存Thread Cache、中央缓存Central Cache、页缓存Page Cache一层比一层接近底层内存一层比一层锁的粒度更大。线程缓存是线程私有的完全无锁中央缓存被所有线程共享但只锁独立的哈希桶页缓存管理真正的物理页锁的粒度更大但频率更低。三层配合既保证了高频小内存分配的速度又保证了整体的内存利用率。上一篇已经把架构图和数据流讲过了这篇不再重复。这篇的核心重点是两个一是每个关键结构为什么要设计成那样二是当你把代码写出来跑起来之后会撞上哪些前面完全想不到的坑。2. 三层架构的核心实现与关键参数2.1 线程缓存的无锁前提线程缓存能无锁前提条件是它完完全全属于当前线程别的线程摸不到。实现方式就是C11的thread_local关键字每个线程第一次访问时创建自己的实例线程销毁时跟着销毁。代码大概是这个样子static thread_local ThreadCache t_cache; ThreadCache* GetThreadCache() { return t_cache; }很多人第一次写的时候有个误区觉得ThreadCache内部有链表、有计数器多个线程用同一个ThreadCache对象就会竞争于是给ThreadCache也加了锁。其实完全没必要thread_local保证了每个线程访问的是自己的副本天然隔离加锁纯属浪费。ThreadCache内部的核心是FreeList数组我用的是定长数组加自由链表的方式。自由链表的关键技巧是空闲对象的内存空间本身可以用来存next指针不需要额外分配节点。也就是说把对象的前8个字节当作next指针用对象空闲时就串在链表上被分配出去后这块空间自然归还给用户。这样设计省掉了链表节点的内存开销和管理成本而且内存地址计算极其简单性能很好。class FreeList { public: void Push(void* ptr) { void** next (void**)ptr; *next free_list_; free_list_ ptr; } void* Pop() { void* obj free_list_; free_list_ *(void**)free_list_; return obj; } void PushRange(void* start, void* end, size_t n) { *(void**)end free_list_; free_list_ start; size_ n; } private: void* free_list_ nullptr; size_t size_ 0; };注意PushRange里的一个细节把一段链表整体挂回free_list_时要保证链表结构不断裂。这里的思路是先把end节点的next指向原来的free_list_再把头指针指向start这样一整块链表就无缝接入现有链表。ThreadCache的核心参数是每个桶允许缓存的最大字节数我这边定的上限是512KB。超过这个阈值就必须把多余的内存还给中央缓存防止某个线程大量申请后囤积内存不释放导致整个池子的内存被少数线程占满。这个参数需要调后面实测部分细说。2.2 中央缓存如何用“细粒度锁”控制竞争中央缓存是共享的必然需要锁但锁的范围可以拆得很细。我的做法是维护一个CentralCache类的静态实例内部有多个哈希桶每个桶一把锁。不同大小的内存块走不同的桶只有两个线程同时申请同样大小范围的块时才会争同一把锁不同大小互相不干扰。这比一把全局锁强太多了实测下来并发了几个线程申请不同大小的块中央缓存基本不成为瓶颈。中央缓存另一个关键设计是批量转移机制。线程缓存向中央缓存要内存时不是要一个给一个而是按批给这个批的大小我用了这样的计算公式size_t BatchNum(size_t size) { // 每次从中心缓存搬的数量越大则搬运次数越少但线程本地积压越多 size_t batch std::max(2, (int)(64 * 1024 / size)); batch std::min(batch, (size_t)512); return batch; }64KB除以对象大小确保搬过来的总内存量大约维持在64KB量级但同时限制在512个以内避免单次搬运过多。这个64KB和512两个数都是经验值如果你发现线程缓存命中率低可以适当调大batch如果发现从中央缓存拿一次耗时太长就调小batch。2.3 页缓存的Span管理与合并策略页缓存管理的单位是页一页假设是4KB跟操作系统常见页大小一致。页缓存手里的每一块连续内存叫SpanSpan记录了起始页号、页数、状态。空闲的Span挂在页缓存的哈希桶里按页数分桶1页、2页、4页、8页一直到128页。这个哈希桶的意义是申请1页就能直接找到1页的桶而不需要从大块里切。但更重要的逻辑是切分和合并。向页缓存申请一个Span时页缓存先看对应页数的桶里有没有货没有就往更大的桶找找到大的Span后切一块出来剩下的部分重新挂到更小页数的桶里。这里有个顺序问题切出来的是Span的尾部还是头部我当时调试了很久发现切尾部的实现更简洁——因为大Span挂回桶里时记录的起始页号不变切出去的是后面的页原Span的page_id不用改直接更新页数重新入桶就行。合并发生在回收的时候。当CentralCache发现一个span里所有对象都归还了就会把这个span整体还给页缓存。页缓存收到一个span先看它的前一页和后一页是否也是空闲的是就合并成一个更大的span继续往上看下一页形成一个递归合并的过程。这一步很关键因为它直接决定长期运行后内存碎片化程度。如果合并策略不做线程不断申请释放不同大小的块页缓存里会散落一堆无法使用的小块最终分配不出大内存。合并的代码关键片段Span* MergeSpan(Span* span) { // 合并前一页 PageID prev_id span-page_id_ - 1; Span* prev_span GetSpanByPageId(prev_id); if (prev_span prev_span-is_free_ prev_span-page_count_ 0) { span-page_id_ prev_span-page_id_; span-page_count_ prev_span-page_count_; RemoveSpanFromList(prev_span); // 继续向前合并 } // 向后合并同理 }合并时有个非常容易踩的坑每个Span的页号和页数确定了一段地址区间必须保证被合并的Span确实是地址相邻且空闲的不能只看页数或者只看状态。我之前有个版本只看空闲状态没查地址连续结果合并出了一个地址断层的“假大块”分配出去后写到中间空洞直接段错误查了整整一天才定位到。3. 大小分级与映射规则数学题要做对3.1 定长对齐追求零内碎片高并发内存池的核心思想之一是“小内存按定长分桶”也就是把不同大小请求对齐到固定的规格。对齐规格怎么设计我采用的是业界常见的分段式对齐1到128字节按8字节对齐129到1024字节按16字节对齐1025到64KB按128字节对齐64KB以上直接走页缓存按页分配。用8字节对齐举例申请13字节实际分配16字节的桶申请31字节分配32字节的桶。这样造成的浪费叫内碎片平均浪费不超过7字节8字节对齐的情况下最多浪费7字节。如果全部按8字节对齐小内存的浪费可以接受但对大块内存也按8字节对齐显然浪费太多这就是为什么要分段式对齐越大的块对齐跨度越大。映射公式大概是static size_t SizeToIndex(size_t size) { if (size 128) { return (size 7) / 8 - 1; } else if (size 1024) { return 16 (size 15) / 16 - 9; } else if (size 64 * 1024) { return 16 57 (size 127) / 128 - 9; } return -1; }这个公式有个细节用(size align - 1) / align来实现向上取整。所有向上对齐的计算都必须用这个公式不能直接写size / align * align后者遇到正好整除和未整除的情况都会算错。另一个容易踩的坑是哈希桶的数量一定要覆盖到最大规格。比如对齐到128KB的桶位申请129KB的内存时SizeToIndex会返回-1应该走页缓存路径而不是直接数组下标访问。我曾经漏了这个判断导致size超限时数组越界程序崩溃的行为非常随机一会儿是段错误一会儿是数据被莫名改写。3.2 从ThreadCache到CentralCache的回退路径当线程缓存某个桶空了需要向中央缓存要一批内存。这时涉及两个层面的逻辑一是从中央缓存的对应桶取出一个Span二是从这个Span里切出一批对象挂到线程缓存的自由链表上。这里要特别注意取出的Span可能已经有部分对象被分配出去了记录在span的used_count_里所以要从自由链表的头部摘取对象每摘一个used_count_加1。反过来线程缓存释放内存时如果本地积压超过512KB阈值执行一次回收操作把自由链表上的一部分对象归还到中央缓存的Span中。每次归还的个数同样用BatchNum控制不能一次全还也不能一个一个还。目的是控制锁的持有时间——归还操作需要持锁持锁时间越长其他线程等待越久。3.3 跨线程释放的问题归属权不是你想的那样这项可能是高并发内存池最容易被忽视的坑。多数人第一版实现的假设是谁分配的内存就由谁释放线程缓存自然归属正确。但真实业务场景中A线程分配的内存很可能被B线程释放比如一个任务线程创建对象丢给另一个线程去销毁。如果释放时简单粗暴地把内存挂到释放线程的ThreadCache上问题就来了这段内存所属的Span可能并不在B线程的ThreadCache管理范围内B线程自由链表上挂着“别人的内存”下次B线程直接拿出去分配但这段内存实际是从A线程的某个Span切出来的两个线程操作同一块内存区域数据竞争必然出现退一步讲就算B线程把它挂到自己链上A线程的Span状态统计就乱了内存池无法判断Span是否真正空闲回收逻辑直接失效。解决办法是在释放路径上做一个判别从传入的内存地址算出它所在的页号再通过页号找到它所属的Span接着看这个Span把内存记在哪个线程名下。最直接的方案是每个CentralCache的Span记录一个所有权标记或者统一把跨线程释放的内存直接归还给中央缓存不经过线程缓存。归还给中央缓存就意味着要加锁但这部分跨线程释放属于少数情况对整体性能影响可控。我最终采用的是只允许线程缓存处理“本线程分配的内存”遇到外部归还时直接落到中央缓存宁可让这种少数路径慢一点也要保证所有线程不踩同一块内存。所以在你设计ThreadCache的Release接口时一定要加一个所有权判断。否则后面并发测试一开崩溃频率会高到让你怀疑整个设计。4. 锁的优化路径每个锁都要能说清楚为什么存在4.1 从一把大锁到桶级锁我第一版图省事CentralCache就一把大锁所有线程的所有分配请求都抢这一把锁最终性能比malloc还差。后来改成桶级锁实测提升立刻立竿见影。但桶级锁也有讲究哈希桶数组就几百字节多个桶的锁变量如果挨得很近会出现伪共享问题也就是某个线程修改了桶A的锁却导致持有桶B锁的线程缓存行失效。解决办法是给每个桶的锁做对齐填充让每个锁占满一个缓存行通常64字节。struct CentralBucket { FreeList free_list_; std::mutex mutex_; // 补齐到缓存行大小防止伪共享 char padding_[64 - sizeof(std::mutex) % 64]; };当然这是用结构体对齐或者宏定义处理的具体写法不同编译器略有差异。有些实现会用std::hardware_destructive_interference_size但我更倾向于手工算对齐简单直接反正不同平台的缓存行基本都是64字节。4.2 页缓存锁的持有时间页缓存锁的粒度比中央缓存更粗但它的操作频率更低。页缓存经常需要做Span的切分和合并这些操作比较复杂持锁时间比较长。为了优化可以先把要合并的Span从桶里摘下来批量合并完再一次挂回去而不是合并一步挂一次。另一个技巧是切分和合并的操作只涉及页号、页数这些元数据不涉及实际内存内容所以可以在持锁状态下做一些轻量级的指针操作尽量不要在锁内调用可能阻塞的系统调用。页缓存底层向操作系统要内存时我用的是mmap或malloc获取一大块内存再把这块内存按页拆分挂到空闲桶里。申请大块内存本身是慢操作不要频繁触发最好一次申请足够大比如256页留作家底。如果每次缺几页就去系统要几页系统调用开销直接吃掉所有优化收益。4.3 无锁化的一小步CAS替换锁的尝试我们在CentralCache的一个热点桶上尝试过把std::mutex换成无锁栈用原子CAS来Push/Pop。结果发现收益有限但复杂度上升不少还引入了ABA问题一个线程A从链上摘走节点时线程B在中间插入又摘走了其他节点导致A拿到的新链表头指针值和它之前读到的旧值一样但链结构已经变了。经典解法是给节点附带版本号比较交换时连版本号一起比。无锁方案虽然在无竞争情况下更快但在竞争激烈的场景下CAS自旋反而可能比互斥锁更差因为互斥锁会让线程休眠把CPU让出来。内存池申请的临界区非常短线程休眠唤醒的开销可能比自旋还大。我最终的结论是CentralCache用细粒度互斥锁就够没必要强行无锁化。这条建议给所有想折腾无锁的同仁先确定锁竞争是不是你的真实瓶颈再决定要不要上复杂度。盲目无锁到头来只会收获更多bug。5. 实测数据与调参记录5.1 怎么测才公平测内存池性能最大的坑是测试方法本身不严谨。如果你用单线程持续分配释放内存池的ThreadCache命中率高数据当然好看但说明不了并发价值。我建议的测试模型是起N个线程每个线程循环执行分配和释放分配大小从4字节到4KB随机分配后立刻释放或者暂存一部分再释放模拟真实业务形态。更重要的一点测试前先预热几万次让每个线程的ThreadCache和CentralCache的Span都进入稳定状态否则前几轮的冷启动数据会严重干扰判断。5.2 我实测下来的一组数据在8核机器上开8个线程交替分配和释放64字节随机块单线程模式下比malloc快约5%到10%8线程满并发下比malloc快2到3倍。线程数越多、并发程度越高、对象越小优势越明显。如果只开2线程而且分配频率不高内存池甚至不一定能赢过malloc因为频繁加锁、维护数据结构的开销大于系统分配器的优化效果。这个结论很重要不是所有业务都适合上内存池高并发、高频率、小对象的场景才是它的主场。5.3 需要调的三个参数第一个是线程缓存上限。默认512KB如果你发现运行一段时间后内存占用快速增长但活跃业务内存并没有那么多大概率是线程缓存囤积太多可以把上限降到256KB。反过来如果命中率低导致central lock竞争大可以适当提高上限。第二个是BatchNum里的64KB基数。这个值决定线程缓存每次从中央缓存拿多少对象。基数过大线程本地缓存积压多、归还频率低基数过小分配两次就要去抢锁。实测下来64KB在多数场景下是不错的折中但你要是做极端业务比如大量4字节小对象建议把batch上限调大一点减少搬运次数。第三个是对齐规则。128字节以上的块用128字节对齐意味着如果你频繁申请129到256字节的内存实际分配的块可能比请求大很多内碎片率上升。如果你内存资源紧张可以把256字节以上的块改成256字节对齐或者增加对齐档位。对齐档位越多内碎片控制越好但哈希桶数量膨胀中央缓存锁数量和内存占用也会涨。这是一个典型的空间和复杂度换性能的权衡。5.4 性能数据的解读套路看内存池性能报告别只看平均值要重点看P99和P999延迟。平均值容易被大多数快速路径掩盖但长尾延迟才反映锁竞争和系统调用带来的卡顿。如果你的P999延迟有明显尖刺优先怀疑几个地方是不是有线程缓存回收大量内存时把central锁占太久是不是页缓存缺页时现场申请大块内存是不是测试进程被操作系统调度影响了。逐个排查后再对着数据调参数不要一上来就改结构。6. 常见问题与排查技巧实录| 现象 | 可能原因 | 排查方向 | | 多线程测试出现偶发崩溃 | 跨线程释放走进了别人的ThreadCache | 检查释放路径是否做了归属判断加页号到Span的反查机制 | | 运行越久内存占用越高 | 线程缓存超额囤积或合并策略失效 | 检查线程退出时是否归还ThreadCache页缓存合并逻辑是否被某个状态位阻塞 | | 分配速率不稳时快时慢 | 页缓存频繁向系统申请大块内存 | 在页缓存申请大块内存路径加日志统计触发频率 | | 和malloc对比性能提升不明显 | 测试场景不是高并发、小对象或锁竞争集中在一两个桶 | 开多线程、提高分配频率观察所有大小桶的锁冲突计数 | | 某些大小对象分配后内存地址有大量空洞 | 跨线程释放导致Span used_count异常 | 在Span的分配和释放路径加计数器校验 | | 程序运行时出现段错误且地址随机 | 合并Span时没检查地址连续性 | 在合并前打印相邻Span的page_id和状态人工核对地址是否连续 |最常见的两个坑我给你展开说说。第一个坑是线程退出时ThreadCache没有归还。很多第一版实现忽略了线程退出这个钩子线程结束就把ThreadCache对象直接销毁了里面积压的内存没人还直接泄漏。这里可以在线程函数收尾时调用一个ReleaseAll函数把ThreadCache里每个桶的FreeList整体归还到CentralCache。这样还能顺带减少整体内存峰值因为线程退出后池子里积压的内存会被释放回操作系统或页缓存复用。第二个坑是对象释放到错误的桶。这个很隐蔽当你调用Delete时传入的size和你实际分配时的size不一致比如从32字节桶里拿的对象释放时被当成64字节桶归还。结果要么挂在错误的链上后续分配拿到写坏的对象要么Span的统计完全错乱回收时误判Span空闲把它合并后分配给其他线程。防这个问题的常规做法是在每个对象的头部附近记录它的实际size或者严格约定调用方必须用相同的size分配和释放。如果你的池子服务内部项目我建议设计一个带size信息的包装Release接口宁可多传一个参数也别让用户手算出错。排查这类问题最有效的手段是在关键路径上加统计计数累计分配次数、释放次数、跨线程释放次数、Span空闲归还次数。四项对账如果分配次数和释放次数对不平、Span永远回收不了基本就能锁定是归属或统计错误。我甚至会在调试版本里用bitmap标记每个页的分配状态定期校验比靠眼睛看日志高效得多。关于调试工具我强烈建议第一版先跑在帮助检测内存错误的工具环境下比如编译器的地址消毒器或者类似功能它能直接帮你捕获越界写、释放后再使用和部分数据竞争问题。内存池这类自己管理内存的系统普通工具可能误报“释放非malloc内存”这时候可以对工具做针对性配置或者用自定义分配器这个阶段忍一忍等全链路跑稳了再关掉。最后再分享一个调优的小技巧页缓存的起始地址最好按页边界对齐。因为页缓存通过page_id和地址的换算非常频繁地址按页对齐后取页号只需要右移12位一页4KB换算成本几乎是零。如果起始地址不对齐每次换算都要做一次除法性能虽然不至于崩但积少成多在每秒几十万次分配的规模下差距非常明显。我自己就是因为这个对齐问题把某个内存池的吞吐从每秒100万次提到了150万次改动只有一行地址对齐的代码。这套高并发内存池做到现在我的体会是没有哪个单点设计能直接决定成败每一层都要各司其职线程缓存管快、中央缓存管调度、页缓存管整合再配合好用的统计和调参手段。后续可以扩展的方向还有不少——比如支持固定大小对象池、加入内存池自带的对象构造析构钩子、做更精准的碎片率监控或者用内存池统一替换项目里所有new/delete调用。真要彻底做深一个池子能玩一整年。
