13、内存池与对象池：内存碎片问题、内存池设计原理、固定大小内存池、对象池实现、tcmalloc/jemalloc简介

聊到高性能服务器，内存管理是个绕不开的话题。我见过不少项目，业务逻辑写得漂漂亮亮，一到压测就崩，追查下来往往是内存碎片在作祟。今天我们就来彻底聊聊内存池和对象池——这两个东西，说白了就是给内存分配做“精细化管理”。

13.1 内存碎片问题：你系统里的“隐形杀手”

先说说内存碎片。你想想看，程序跑着跑着，malloc和free交替进行，内存就像一块瑞士奶酪，到处是洞。这些洞单个看都不大，但加起来就是一大片空闲空间，却没法分配出一个连续的大块内存。

碎片分两种：

• 外部碎片：已分配内存之间的空闲小块，无法合并成大块使用
• 内部碎片：分配的内存块比实际需求大，多出来的部分被浪费了

我在项目中遇到过最夸张的一次，一个游戏服务器跑了48小时，内存占用显示还剩2GB，但申请一个64KB的buffer都失败了。为什么？因为那2GB被切成了成千上万个32字节、64字节的小碎片，没有一个连续区域能放下64KB。

13.2 内存池设计原理：从“随用随取”到“批量管理”

内存池的核心思想其实很简单：提前申请一大块内存，然后自己管理这块内存的分配和释放。不再每次都找操作系统要，而是从池子里拿。

这样做的好处很明显：

• 减少系统调用（malloc/free背后是brk/mmap，开销不小）
• 避免内存碎片（同一池子里的内存块大小固定，不会切碎）
• 分配速度快（池子里拿，O(1)复杂度）

一个基本的内存池设计，通常包含这几个要素：

1. 预分配：一次性从系统申请大块内存（比如64KB或1MB）
2. 分块管理：把大块切成若干小块，用链表或位图记录哪些空闲
3. 分配接口：从空闲链表中取一个块返回
4. 释放接口：把用过的块归还到空闲链表

嗯，这里要注意：释放时不是还给操作系统，而是还给池子。这样下次分配就能复用，效率极高。

13.3 固定大小内存池：最经典的实现

固定大小内存池，说白了就是只管理一种大小的内存块。比如你的业务里大量用到128字节的buffer，那就专门搞一个128字节的池子。

实现起来其实不复杂，我直接给个核心骨架：

class FixedSizePool {
private:
    struct Block {
        Block* next;  // 空闲链表指针
    };
    Block* free_head_;  // 空闲链表头
    void*  pool_start_; // 池子起始地址
    size_t block_size_; // 每个块的大小
    size_t pool_size_;  // 池子总大小

public:
    FixedSizePool(size_t block_size, size_t block_count) 
        : block_size_(block_size), free_head_(nullptr) {
        // 一次性申请
        pool_size_ = block_size * block_count;
        pool_start_ = malloc(pool_size_);
        
        // 初始化空闲链表
        char* p = static_cast<char*>(pool_start_);
        for (size_t i = 0; i < block_count; ++i) {
            Block* b = reinterpret_cast<Block*>(p + i * block_size);
            b->next = free_head_;
            free_head_ = b;
        }
    }

    void* allocate() {
        if (!free_head_) return nullptr;  // 池子空了
        Block* b = free_head_;
        free_head_ = free_head_->next;
        return b;
    }

    void deallocate(void* ptr) {
        Block* b = static_cast<Block*>(ptr);
        b->next = free_head_;
        free_head_ = b;
    }

    ~FixedSizePool() {
        free(pool_start_);
    }
};

你看，核心就几十行代码。allocate和deallocate都是O(1)操作，比malloc快一个数量级。我在一个消息中间件项目里用过这个模式，每秒处理10万条消息，内存分配几乎零开销。

13.4 对象池：比内存池更进一步

对象池和固定大小内存池很像，但有个关键区别：对象池不仅管理内存，还管理对象的构造和析构。

你想想看，有些对象创建成本很高——比如要打开数据库连接、要初始化SSL上下文。每次都new+构造，用完再delete+析构，太浪费了。对象池的做法是：对象用完了不析构，只是重置状态，放回池子里等下次复用。

实现上，对象池通常提供两个核心操作：

• acquire()：从池子里拿一个对象，如果池子为空则新建
• release(obj)：把对象归还池子，重置状态但不析构

我举个例子，一个简单的连接池：

template<typename T>
class ObjectPool {
private:
    std::vector<T*> pool_;
    std::mutex mtx_;
public:
    T* acquire() {
        std::lock_guard<std::mutex> lock(mtx_);
        if (pool_.empty()) {
            return new T();  // 池子空了就新建
        }
        T* obj = pool_.back();
        pool_.pop_back();
        obj->reset();  // 重置状态
        return obj;
    }

    void release(T* obj) {
        std::lock_guard<std::mutex> lock(mtx_);
        pool_.push_back(obj);  // 归还池子
    }
};

13.5 tcmalloc/jemalloc：工业级的内存分配器

聊完自己手写的池子，我们来看看工业界是怎么做的。tcmalloc（Google出品）和jemalloc（Facebook在用）是现代C++高性能服务的标配。

它们解决了什么问题？

• 多线程竞争：glibc的malloc在多线程下性能很差，因为全局锁
• 内存碎片：glibc的ptmalloc在长期运行后碎片严重
• 局部性：好的分配器能让相关数据在物理上靠近，提高缓存命中率

我简单对比一下两者的特点：

特性	tcmalloc	jemalloc
核心思想	每个线程有自己的缓存（Thread Cache）	每个CPU核心有自己的arena
小对象处理	固定大小类，类似我们上面讲的固定大小池	使用slab分配器，类似内核做法
大对象处理	直接mmap，页对齐	使用红黑树管理大块内存
内存占用	相对较高（为了速度牺牲空间）	更节省，碎片控制更好
适用场景	高并发、小对象频繁分配	内存敏感、长时间运行的服务

我个人习惯是：如果项目对延迟要求极高，选tcmalloc；如果内存有限且要跑几天几周，选jemalloc。当然，现在很多项目直接上jemalloc，因为它在碎片控制上确实更胜一筹。

嗯，关于内存池和对象池，我们就聊到这里。这些东西看起来基础，但用好了，你的服务器性能能上一个台阶。下次遇到内存碎片问题，你知道该从哪里下手了。

---

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