malloc在高频小对象分配时变慢，因其每次调用可能触发系统调用、加锁、遍历空闲链表及处理碎片，开销远超实际内存操作；固定尺寸内存池通过预分配+单链表管理实现o(1)无锁分配回收，提升局部性并避免碎片整理。
为什么 malloc 在高频小对象分配时会变慢？
因为每次调用 malloc 都可能触发系统调用（如 brk 或 mmap），还要加锁、遍历空闲链表、处理碎片。小对象（比如 16–256 字节）反复分配释放时，这些开销占比极高，甚至超过实际内存操作本身。
- 系统调用不是“免费”的：一次
sbrk或mmap可能要几百纳秒，而 CPU 缓存内指针运算只要几纳秒 - 默认分配器为通用性妥协：glibc 的
ptmalloc维护多层结构（fastbins / unsorted bin / small bins），但单线程高频场景下锁和元数据更新反成瓶颈 - 内存局部性差：
malloc返回的地址分散，容易导致 cache line miss
用固定大小块（fixed-size slab）实现最简内存池
适合已知对象尺寸、生命周期相近的场景（如网络包缓冲区、AST 节点、游戏实体组件）。核心是预分配一大块内存，按固定步长切分成 slot，用单链表管理空闲项。
- 分配只需取链表头：
free_list = free_list->next，O(1)，无锁（单线程）或轻量 CAS（多线程） - 回收只是插回链表头，不合并、不遍历，避免碎片整理开销
- 对齐必须显式控制：用
alignas(64)或手动偏移确保每个 slot 满足缓存行对齐，否则伪共享（false sharing）会抵消性能收益 - 示例关键片段：
class FixedPool { char* memory_; size_t block_size_; char* free_list_; // ... void* allocate() { if (!free_list_) return nullptr; char* ptr = free_list_; free_list_ = *reinterpret_cast<char**>(ptr); // 头插法复用前 8 字节存 next return ptr; } };
多尺寸池（size-classed pool）如何避免内部碎片？
纯 fixed-size 池在对象尺寸波动时浪费严重（比如申请 49 字节却得用 64 字节 slot）。真实项目通常按幂级分组（如 16/32/48/64/80/96/112/128/… 字节），每组一个独立 FixedPool 实例。
- 尺寸映射不能用除法或循环查找：用查表（
size_classes[256]）或位运算（如(size + 15) & ~15粗略对齐后查 LUT） - 注意边界情况：0 字节分配需特殊处理（返回 nullptr 或转为最小尺寸），
sizeof(void*)以下的请求容易被忽略但实际存在（如空 struct） - 不要盲目增加分类数：glibc 的 malloc 用 64+ 个 bin，但你的业务若 95% 请求集中在 3 种尺寸，只建 3 个池更高效
- 兼容性提示：C++17 起可配合
std::pmr::memory_resource接口，让容器（如std::pmr::vector）透明使用你的池
释放后内存是否立即归还给 OS？
几乎从不。预分配的大块内存（如 mmap 得到的 2MB 区域）通常整个生命周期内都保留在进程地址空间里，除非你显式调用 munmap —— 但这有代价：重分配时又要 mmap，且无法部分释放。
立即学习“C++免费学习笔记（深入）”；
- 常见误解：“内存池能减少 RSS” → 实际上它把“频繁小 mmap/munmap”换成“长期持有一大块”，RSS 更稳但未必更小
- 真正省的是系统调用次数和分配延迟，不是物理内存用量
- 若真需要归还，得自己维护页级空闲状态（比如记录哪些 4KB 页全空闲），再批量
madvice(MADV_DONTNEED)，但多数服务更看重延迟稳定性，而非 RSS 数值 - 多线程下尤其注意：一个线程释放的内存，可能被另一个线程立刻复用，此时绝对不能 munmap
内存池不是银弹。对象生命周期混杂、尺寸不可预估、或单次分配量极少时，引入池反而增加复杂度和内存占用。真正关键的是测量——用 perf record -e syscalls:sys_enter_mmap,syscalls:sys_enter_brk 看你的热点是不是真卡在分配路径上。
