1、内存分配器概述：为什么需要内存池？

大家好，我是你们的老朋友。今天咱们来聊聊内存池这个话题。

说实话，我刚开始做C语言开发那会儿，对malloc/free这套机制还挺满意的。直到有一次，我负责一个网络服务器项目，每秒要处理上万次请求。结果呢？程序跑着跑着就卡顿了，内存占用忽高忽低，最后直接崩了。排查了半天，罪魁祸首就是频繁的内存分配和释放。

从那以后，我就开始认真研究内存池了。今天咱们就好好聊聊，为什么需要内存池，以及malloc/free到底有哪些痛点。

1.1 malloc/free的痛点

先说说malloc/free。这两个函数是C标准库提供的内存管理接口，看起来简单好用。但实际项目中，它们的问题可不少。

我总结了一下，主要有这几个问题：

• 系统调用开销大：每次malloc/free都可能触发系统调用，从用户态切换到内核态。这个切换成本可不低，尤其是高频调用时。
• 内存碎片化：频繁分配释放小内存，会导致内存碎片。明明总内存够用，但就是分配不出连续的大块内存。
• 锁竞争严重：多线程环境下，malloc/free内部有锁保护。线程多了，锁竞争就成了性能瓶颈。
• 不确定性：分配时间不确定，可能很快，也可能很慢。这对实时系统来说是个大问题。

1.2 内存碎片问题

内存碎片，说白了就是内存被切成了很多小块，像拼图一样散落在各处。你想想看，明明有100MB空闲内存，但最大连续块只有1MB，这时候想分配2MB的内存，就失败了。

我遇到过最夸张的一次，是在一个嵌入式设备上。程序跑了三天后，malloc突然返回NULL了。检查内存总量，还有30%空闲。但就是分配不出一个4KB的缓冲区。这就是典型的内存碎片问题。

内存碎片分两种：

碎片类型	产生原因	典型场景
外部碎片	多次分配释放后，空闲内存被分割成不连续的小块	频繁分配不同大小的内存
内部碎片	分配的内存块大于实际需求，造成浪费	对齐要求导致的额外空间

1.3 性能瓶颈分析

咱们来做个简单的性能分析。假设你的程序每秒要分配释放10000次内存，每次分配64字节。用malloc/free的话，大概是什么情况？

我实测过，在普通Linux服务器上，每次malloc/free大约需要100-200纳秒。但这是理想情况。如果内存碎片严重，或者多线程竞争激烈，这个时间可能飙升到微秒级别。

更关键的是，malloc/free的时间是不确定的。你永远不知道下一次分配要花多久。这对高性能系统来说，是个大隐患。

我举个例子：

// 传统malloc/free方式
for (int i = 0; i < 10000; i++) {
    void *p = malloc(64);
    // 使用内存...
    free(p);
}

// 内存池方式
MemoryPool pool;
pool_init(&pool, 64, 10000);
for (int i = 0; i < 10000; i++) {
    void *p = pool_alloc(&pool);
    // 使用内存...
    pool_free(&pool, p);
}
pool_destroy(&pool);

你看，内存池的方式，分配和释放都是常数时间，而且没有系统调用，没有锁竞争。性能差距有多大？我实测过，内存池比malloc/free快10-100倍。

1.4 为什么需要内存池？

说白了，内存池就是针对特定场景定制的内存管理方案。它预先分配一大块内存，然后自己管理这块内存的分配和释放。

这样做的好处很明显：

• 性能高：分配释放都是常数时间，没有系统调用
• 无碎片：固定大小分配，不会产生外部碎片
• 确定性：分配时间可预测，适合实时系统
• 线程安全：可以设计无锁的内存池，避免锁竞争

下面这张图，展示了内存池的核心思想：

嗯，这里要注意一点。内存池不是万能的。它最适合固定大小内存块的场景。如果你的程序需要分配各种不同大小的内存，那传统的内存池就不太合适了。不过别担心，后面我们会讲到更高级的分配器设计。

我个人习惯是，在项目初期就评估好内存使用模式。如果发现是固定大小、高频分配的场景，直接上内存池。省得后期优化时手忙脚乱。

好了，这一章就到这里。咱们下一章见。

---

公众号:蓝海资料掘金营，微信deep3321