高并发内存池 - central cache 结构设计项目 gitee 链接 高并发内存池项目项目 github 链接 高并发内存池项目central cache 也是一个哈希桶结构并且映射关系与 thread cache 保持一致但是链接部分不再是自由链表而是一个名为SpanList的链表结构链表的存储对象是名为span的大内存块span中存储着切割好的小内存块链接而成的自由链表当 thread cache 申请时便返回的是自由链表的部分。这里有几点需要注意对于central cache线程与进程均共享一个所以设计为单例模式central cache有被多进程并发访问的可能多个 thread cache 同时没有资源同时请求所以要设计锁对于锁的位置需要分析一下多个 thread cache 可能申请的不是一个桶中的资源比如一个申请 6KB一个申请 8KB所以不能给 central cache 整体上锁而是只在哈希桶内部上锁确保桶只能在任意时刻被一个线程访问。下面我们深入探索一下谈谈为何这么设计而不是只困在应该这么设计为何要使用 Span如果还使用自由链表去设计 central cache 这一层就会产生一个致命的问题内存泄露假设 central cache 使用自由链表设计现在这个程序已经运行了很长时间多线程疯狂申请和释放 8 字节的内存。此时CentralCache 的 8 字节桶里有一个超级巨大的自由链表里面串着 100 万个 8 字节的空闲内存块总共占用了约 8MB 的物理内存。灾难发生了程序突然进入了低谷期不再需要这些小内存了。这时候你想把这 8MB 的内存还给操作系统或者借给需要 16 字节内存的桶用你该怎么做面对单纯的自由链表你绝望了。因为自由链表里的节点是打散的这 100 万个 8 字节内存块可能散布在 2000 个不同的物理页Page中每个页里只闲置了一半的内存另一半还在被其他线程使用。操作系统的规则是冷酷的你必须把完整的一页4KB或连续的几页原封不动地还给我我才能回收。你不能把“半页”内存还给我。结果你的内存池患上了“内存泄漏”的绝症。那 8MB 内存永远卡在 CentralCache 的巨大链表里既无法被其他大小的桶使用也无法还给操作系统只能白白浪费。结论单纯的自由链表只能“借出”内存很难完整地“收回”内存。此时的破局之道便是引入 Span。Span 申请的是连续的内存页块当 thread cache 需要内存是Span 对大块内存进行分割将分割后的小块内存进行分配对已经使用的小块内存数进行记录如果最后使用的内存都已归还说明此时这块连续的物理内存已经空闲可以将其打包再还给上层解决内存泄露与外部碎片的问题。总结实现内存的 “有借有还”核心目的ThreadCache为什么不需要 Span 因为ThreadCache是线程私有的它的设计哲学是“只管拿不管还”。它把内存囤在自己手里是为了极致的分配速度。就算内存浪费也只浪费在当前线程。CentralCache是全局共享的枢纽。它必须承担回收内存、降低系统整体内存水位的责任。Span 是内存回收的最小管理单元。没有 SpanCentralCache就无法把打散的内存重新聚合成完整的“页”还给 OS。解决外部碎片问题如果CentralCache直接用大链表长时间运行后物理内存会被切得稀碎这里空 8 字节那里空 16 字节导致程序明明有 100MB 空闲内存却无法申请一个连续的 1MB 内存块这就是外部碎片。使用Span内存总是以“连续的页”为单位申请和释放保证了物理内存的连续性极大地减少了外部碎片。提高分配效率局部性原理当ThreadCache来进货时CentralCache会优先从同一个Span里连续切出多个小块给它。这些小块在物理内存上是紧挨着的。当 CPU 去访问这些内存时能极大地提高CPU CacheL1/L2缓存的命中率从而提升整个程序的性能。如果是单纯的大自由链表拿出来的内存块在物理地址上可能是东一个西一个CPU 缓存命中率会很低。