8. 内存分配优化：栈分配 vs 堆分配、内存池、对象池、减少动态分配

内存分配，这个话题我聊了快二十年了。说实话，很多性能问题追根溯源，最后都卡在内存分配上。你想想看，一个malloc下去，操作系统要翻页表、找空闲块、还可能触发缺页中断——这一套组合拳打下来，几十微秒就没了。在高频交易或者游戏引擎里，这几十微秒足够让帧率掉一截。

我个人习惯是：能栈分配绝不堆分配。这不是偏执，是实打实的性能考量。

栈分配 vs 堆分配：速度差在哪？

栈分配本质上就是移动一下栈指针，一条指令搞定。堆分配呢？要调用malloc，要遍历空闲链表，要处理内存碎片。我在项目中遇到过这样一个场景：一个网络服务每秒要处理几万个连接，每个连接都要分配一个小缓冲区。一开始用的堆分配，CPU直接飙到80%。改成栈分配后，CPU降到15%。

为什么会这样？看个对比：

// 堆分配 —— 慢
void handle_request() {
    char *buf = (char*)malloc(1024);
    // 处理请求...
    free(buf);
}

// 栈分配 —— 快
void handle_request() {
    char buf[1024];
    // 处理请求...
    // 自动释放，无需操心
}

栈分配的优点很明显：

• 分配速度极快，几乎零开销
• 自动释放，不会内存泄漏
• 缓存友好，局部性好

但栈也有局限：大小有限（通常几MB），生命周期固定。你没法在函数返回后继续使用栈上的数据。

内存池：解决频繁分配的问题

如果实在避不开堆分配，那就用内存池。说白了，就是一次性向系统申请一大块内存，然后自己管理分配和释放。我在做嵌入式数据库时用过这个技巧——频繁地分配和释放固定大小的记录，用内存池后性能提升了3倍。

一个简单的内存池实现：

typedef struct {
    void *pool;        // 内存池起始地址
    size_t block_size; // 每个块的大小
    size_t capacity;   // 总块数
    void *free_list;   // 空闲链表头
} MemoryPool;

// 初始化内存池
MemoryPool* pool_create(size_t block_size, size_t count) {
    MemoryPool *mp = malloc(sizeof(MemoryPool));
    mp->block_size = block_size;
    mp->capacity = count;
    mp->pool = malloc(block_size * count);
    
    // 构建空闲链表
    mp->free_list = mp->pool;
    char *p = (char*)mp->pool;
    for (size_t i = 0; i < count - 1; i++) {
        *(void**)(p + i * block_size) = p + (i + 1) * block_size;
    }
    *(void**)(p + (count - 1) * block_size) = NULL;
    
    return mp;
}

// 分配 —— 常数时间
void* pool_alloc(MemoryPool *mp) {
    if (!mp->free_list) return NULL;
    void *ptr = mp->free_list;
    mp->free_list = *(void**)ptr;
    return ptr;
}

// 释放 —— 常数时间
void pool_free(MemoryPool *mp, void *ptr) {
    *(void**)ptr = mp->free_list;
    mp->free_list = ptr;
}

注意看，这里的分配和释放都是O(1)的，没有系统调用，没有锁竞争。我在游戏服务器里用这个模式管理玩家对象，每秒几万次分配毫无压力。

对象池：复用而非释放

对象池和内存池有点像，但更进了一步——它不只是管理内存，还管理对象的生命周期。对象用完后不销毁，而是放回池子里，下次直接拿来用。

我曾经优化过一个实时渲染引擎，里面频繁创建和销毁粒子对象。每次new/delete都伴随着构造和析构，开销不小。改成对象池后：

typedef struct {
    Particle particles[MAX_PARTICLES];
    int available[MAX_PARTICLES];
    int top;  // 栈顶指针
} ParticlePool;

Particle* acquire_particle(ParticlePool *pool) {
    if (pool->top <= 0) return NULL;
    int idx = pool->available[--pool->top];
    return &pool->particles[idx];
}

void release_particle(ParticlePool *pool, Particle *p) {
    int idx = p - pool->particles;
    pool->available[pool->top++] = idx;
}

这个模式的好处是：零碎片、零系统调用、零构造析构开销。你想想看，一个粒子从出生到消亡，可能只需要几十毫秒，如果每次都走完整的new/delete，CPU时间全花在内存管理上了。

减少动态分配：从源头优化

最好的优化，就是不分配。嗯，这话听起来有点绝对，但道理没错。很多场景下，动态分配是可以避免的。

我总结了几条实用策略：

• 固定大小缓冲区：如果最大长度已知，直接用数组。比如路径名、IP地址这些，很少超过256字节。
• 栈上变长数组（VLA）：C99支持VLA，可以在栈上分配变长数组。注意别太大，容易栈溢出。
• alloca函数：在栈上动态分配，自动释放。我一般只在临时缓冲区用，不会跨函数传递。
• 复用缓冲区：一个缓冲区反复用，别每次处理都新分配。我在网络编程里常用这个技巧。

// 不好的做法：每次分配
void process_message(const char *data, size_t len) {
    char *copy = malloc(len + 1);
    memcpy(copy, data, len);
    copy[len] = '\0';
    // 处理...
    free(copy);
}

// 好的做法：复用缓冲区
thread_local char buffer[4096];
void process_message(const char *data, size_t len) {
    if (len >= sizeof(buffer)) {
        // 处理大消息，fallback到堆分配
        return;
    }
    memcpy(buffer, data, len);
    buffer[len] = '\0';
    // 处理...
}

你看，第二种做法连分配都省了。对于高频调用的函数，这种优化效果立竿见影。

知识体系总览

下面这张图总结了内存分配优化的核心思路：

实战建议

说了这么多，到底该怎么选？我给出一个决策流程：

1. 先问自己：这个对象能放栈上吗？如果能，直接栈分配。
2. 再问：分配频率高吗？如果每秒上千次，考虑内存池或对象池。
3. 最后问：对象大小固定吗？固定 → 内存池；不固定 → 堆分配 + 复用缓冲区。

我曾经在一个实时音频处理项目里，把所有的中间缓冲区都改成了栈分配，配合几个固定大小的内存池。结果呢？延迟从5ms降到了0.5ms。嗯，这就是内存分配优化的威力。

---

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