【C++】从零实现一个高并发内存池

news2024/11/26 20:38:22

项目简介

技术栈

内存池

内存池解决的主要问题

效率问题

内存碎片问题

整体框架设计

Thread Cache

代码框架

Central Cache

代码框架

Page Cache

代码框架

申请内存流程

Thread Cache

Central Cache

Page Cache

释放内存流程

Thread Cache

Central Cache

Page Cache

项目简介

本项目实现了一个具有三层缓存机制的高并发内存池，项目原型为 google 的开源项目 tcmalloc，tcmalloc 全称 Thread-Caching Malloc，即线程缓存的 malloc，实现了高效的多线程内存管理，用于替代系统的内存分配相关的函数（malloc、free）。

技术栈

C/C++，数据结构（链表、哈希桶），操作系统内存管理，单例模式，多线程，互斥锁。

内存池

内存池是指程序预先从操作系统申请一块足够大内存，此后，当程序中需要申请内存的时候，不是直接向操作系统申请，而是直接从内存池中获取；同理，当程序释放内存的时候，并不真正将内存返回给操作系统，而是返回内存池。当程序退出(或者特定时间)时，内存池才将之前申请的内存真正释放。

内存池解决的主要问题

内存池最关注的问题有两点：一是效率问题，二是内存碎片的问题。

效率问题

首先，我们知道申请内存使用的是 malloc，此函数设计得比较通用，什么场景下都可以用，这也就意味着什么场景下都不会有很高的性能。

malloc 是线程安全函数，但不是可重入函数。在多线程场景下申请内存时，malloc 通过递归锁实现了线程安全，保证多个线程互斥申请内存，这也就使得多线程不能并发申请内存。本项目为每个线程设计了一个 Thread Cache，使得多线程场景下可以并发申请内存。

关于 malloc / free 相关问题可以参考以下文章：

【C语言】一文详解 malloc / free 分配内存和释放内存相关问题-CSDN博客

内存碎片问题

外部碎片：当内存中有足够数量的区域来满足方法的内存请求，但是由于提供的内存是不连续的，因此无法满足进程的内存请求，会导致外部碎片，详见下图：

内部碎片：在分配给方法的内存比请求的内存稍大的情况下，分配的内存和请求的内存之间的差异
称为内部碎片。例如：页帧（page frame）是内存的最小可分配单元，也开始称作页框，Linux 下页帧的大小为4KB，若用户申请3KB，系统会根据最小可分配单元分配4KB，在用户层面仅分配了3KB，于是就只使用3KB，多出来的1KB就是内部碎片。

整体框架设计

现代很多的开发环境都是多核多线程，在申请内存的场景下，必然存在激烈的锁竞争问题。malloc 本身其实已经很优秀，那么我们项目的原型 tcmalloc 就是在多线程高并发的场景下更胜一筹，所以我们实现的内存池需要考虑以下几方面的问题。

性能问题。
内存碎片问题。
多线程环境下，锁竞争问题。

高并发内存池主要由如下3个部分组成：

Thread Cache：线程缓存是每个线程独有的，用于小于256KB的内存的分配，线程从这里申请内存不需要加锁，每个线程独享一个 Cache，这也就是这个并发线程池高效的地方。
Central Cache：中心缓存是所有线程所共享，Thread Cache 是按需从 Central Cache 中获取的对象。Central Cache 合适的时机回收 Thread Cache 中的对象，避免一个线程占用了太多的内存，而其他线程的内存吃紧，达到内存分配在多个线程中更均衡的按需调度的目的。Central Cache是存在竞争的，所以从这里取内存对象是需要加锁，首先这里用的是桶锁，其次只有 Thread Cache 的没有内存对象时才会找 Central Cache，所以这里竞争不会很激烈。
Page Cache：页缓存是在 Central Cache缓存上面的一层缓存，存储的内存是以页为单位存储及分配的，Central Cache没有内存对象时，从 Page Cache 分配出一定数量的 page，并切割成定长大小的小块内存，分配给 Central Cache。当一个 span 的几个跨度页的对象都回收以后，Page Cache 会回收 Central Cache 满足条件的span对象，并且合并相邻的页，组成更大的页，缓解内存碎片的问题。

Thread Cache

Thread Cache 是哈希桶结构，每个桶是一个按桶位置映射对应内存块对象大小的 FreeList 自由链表。采用 TLS 技术使每个线程都有一个 Thread Cache 对象，这样每个线程在这里获取对象和释放对象时是无锁的。

代码框架

Central Cache

Central Cache 也是一个哈希桶结构，他的哈希桶的映射关系跟 Thread Cache 是一样的。不同的是他的每个哈希桶位置挂是 SpanList 链表结构，不过每个映射桶下面的 span 中的大内存块被按映射关系切成了一个个小内存块对象挂在 span 的自由链表中。

代码框架

Page Cache

Page Cache 依然用的桶结构，每个桶下挂的一个 SpanList，每个桶直接按照桶的下标映射 SpanList。

代码框架

申请内存流程

Thread Cache

当内存申请 size<=256KB，先获取到线程本地存储的 Thread Cache 对象，计算 size 映射的哈希桶自由链表下标 i，size 的映射关系如下表。
如果自由链表 _freeLists[i] 中有对象，则直接 Pop 一个内存对象返回。
如果 _freeLists[i] 中没有对象时，则批量从 Central Cache 中获取一定数量的对象，插入到自由链表并返回一个对象。

申请的内存数	对齐数	哈希桶分区
[1, 128]	8 byte	freelist[0, 16)
[128+1, 1024]	16 byte	freelist[16, 72)
[1024+1, 8*1024]	128 byte	freelist[72, 128)
[81024+1, 641024]	1024 byte	freelist[128, 184)
[641024+1, 2561024]	8096 byte	freelist[184, 208)

Central Cache

当 Thread Cache 中没有内存时，就会批量向 Central Cache 申请一些内存对象，这里的批量获取对象的数量使用了类似网络 tcp 协议拥塞控制的慢开始算法；Central Cache 也有一个哈希映射的 SpanList，SpanList 中挂着 span，从span中取出对象给 Thread Cache，这个过程是需要加锁的，不过这里使用的是一个桶锁，尽可能提高效率。
Central Cache 映射的 SpanList 中所有 span 的都没有内存以后，则需要向 Page Cache 申请一个新的 span 对象，拿到 span 以后将 span 管理的内存按大小切好作为自由链表链接到一起。然后从 span 中取对象给 Thread Cache。
Central Cache 中挂的 span 中 use_count 记录分配了多少个对象出去，分配一个对象给Thread Cache，就 ++use_count。

Page Cache

当 Central Cache 向 Page Cache 申请内存时，Page Cache先检查对应位置有没有 span，如果没有则向更大页寻找一个 span，如果找到则分裂成两个。比如：申请的是4页 page，4页page后面没有挂span，则向后面寻找更大的 span，假设在10页 page 位置找到一个 span，则将10页 page span 分裂为一个4页 page span 和一个6页 page span。
如果找到 _spanList[128] 都没有合适的 span，则向系统使用 mmap、brk 或者是 VirtualAlloc 等方式申请128页 page span 挂在自由链表中，再重复步骤1中的过程。
需要注意的是 Central Cache 和 Page Cache 的核心结构都是 SpanList 的哈希桶，但是他们是有本质区别的，Central Cache 中哈希桶，是按跟 Thread Cache 一样的大小对齐关系映射的，Central Cache 的 SpanList 中挂的 span 中的内存都被按映射关系切好链接成小块内存的自由链表。而 Page Cache 中的 SpanList则是按下标桶号映射的，也就是说第 i 号桶中挂的 span 都是 i 页内存。