内存分配器深度剖析：从new/malloc到自定义内存池

在性能优化这条路上绕了几年，我越来越觉得“内存分配器”这个词是被低估的。大多数人写 C++ 程序，对内存的认知止步于 new 和 delete、malloc 和 free，偶尔遇到内存暴涨或者性能毛刺，第一反应是“我是不是内存泄漏了”，很少有人会去想：默认的内存分配器到底是怎么工作的？它为什么慢？几十个线程同时 new 对象的时候，性能瓶颈到底卡在哪？

这个主题看着底层，但其实和日常开发离得特别近。我用一个实际例子说明：项目里有一段处理网络消息的代码，单线程跑很正常，一上多线程压测，吞吐量掉了接近一半。排查到最后，问题不是锁、不是算法，而是高频的 small object 分配让全局分配器成了瓶颈。后来接入了自定义的内存池，再压测数据直接翻了一倍。从那以后，我就把“内存分配器”当成了性能优化工具箱里的头号工具。

这篇文章适合三类人：想搞懂 new 和 malloc 背后原理的学生、正在做服务端或客户端性能优化的工程师、以及写通用库时需要自定义分配器的高级开发者。读完你会发现，内存分配这件事的复杂度远超想象，但也正因为如此，吃透它带来的收益同样远超想象。

1. 先看清分层：从一行 new 到底层内存，中间发生了什么

1.1 new 表达式、operator new 与 malloc 的区别

很多人以为 new 就是“申请内存”，其实这说法不完整。一个标准的 new 表达式，比如 auto obj = new MyClass();，编译器会拆成两步走：先调用 operator new 分配一块原始内存，拿到 void*；然后在这块内存上调用 MyClass 的构造函数。delete 则反过来，先调用析构函数，再调用 operator delete 释放内存。

这个拆分非常关键。它意味着我们可以只拦截“原始内存的分配与释放”这一步，而不影响对象构造和析构的语义。自定义内存分配器的本质，就是替换这个中间环节。

而 operator new 的默认实现，内部调用的又是 C 语言里的 malloc。所以完整链路是：

code复制new MyClass() 
  -> operator new(sizeof(MyClass)) 
    -> malloc(size) 
      -> 操作系统的堆分配机制（brk / mmap）

理解这个链条有几层意义。第一，C++ 的分配并不比 C 的 malloc 更“高级”，无非是多了一层构造语义。第二，只要替换 operator new 或者给容器传入自定义 allocator，就能控制整条内存路径。第三，默认分配器的一切行为特征、性能瓶颈、碎片问题，本质上都是 malloc 层面带来的。

1.2 glibc malloc 的本质：arena、bin 与系统调用

默认分配器里藏着很多有意思的设计。以 Linux 下最常见的 glibc malloc 为例，它并不会每次分配都去找操作系统要内存，那样效率太低，系统调用一次的成本动辄几百纳秒。它的策略是：先向操作系统申请一大块连续内存（专业术语叫 arena），然后在用户态把这块内存切成各种大小的 chunk，自己维护一套空闲链表。

这套机制里涉及几个重要概念。arena 分主 arena 和线程 arena，主 arena 用 brk 扩展堆段，线程 arena 用 mmap 映射匿名内存。每个 arena 里面有多种 bin：fastbin 是 LIFO 的单向链表，专门缓存小内存块；unsorted bin 是释放内存的临时中转站；small bin 和 large bin 按大小分桶管理空闲 chunk。除此之外还有一个 top chunk，相当于一整块待切割的“原石”。

当程序请求 24 字节时，malloc 并不会只给 24 字节。它要加上 chunk 头部的元数据（prev_size 和 size 字段，64 位下合计 16 字节），然后对齐到 16 字节边界，所以实际分配的可能是 32 字节甚至更多。这就是内部碎片的来源之一。另外，如果请求的大小超过阈值（glibc 的默认阈值约 128KB），malloc 会直接走 mmap 分配，返回时再 munmap 释放，看起来干净利落，但代价是每个大块分配都要经历两次系统调用，频繁分配大 buffer 时开销非常可观。

理解这些机制后，很多现象就说得通了。多线程频繁 new 小对象时，所有线程默认竞争同一个主 arena 的锁，分配操作退化成串行，性能自然拉胯。glibc 后来引入了 per-thread cache（tcache）缓解这个问题，但缓存大小有限，而且线程多了以后依然存在锁竞争。

2. 默认分配器的“性格”，决定了它为什么慢

2.1 线程安全与锁竞争：多线程下的分配热点

默认的 malloc/free 是线程安全的，这意味着任何一次分配或释放都必须考虑多线程并发。glibc 的做法是给每个 heap 加锁，虽然引入了 arena 扩展来降低竞争，但本质上仍是锁机制。高频分配场景下，锁等待可能成为比业务逻辑更大的开销。

我做过一个实验：开 8 个线程，每个线程连续做 100 万次 64 字节的分配和释放，用默认分配器的总耗时比单线程跑 8 倍任务还慢好几倍。原因很简单，8 个线程互相抢锁，实际有效工作被严重稀释。换成 jemalloc 或者 tcmalloc 后，同样的并发模型耗时骤降，因为它们用 per-thread cache 把绝大多数分配操作变成了无锁的本地操作。

这也是为什么游戏引擎和中间件系统普遍不信任默认分配器。服务端程序想要稳定低延迟，第一步往往是换成更懂并发的分配器，或者针对具体场景设计专用内存池。默认分配器不是不能用，而是它的通用性决定了它不可能在每个场景都最优。

2.2 内存碎片与利用率：默认分配器的隐藏成本

内存碎片是默认分配器最容易被忽略的代价。外部碎片指空闲内存块被分割成大量不连续的小块，导致明明有足够总空闲空间，却分配不出一个大块；内部碎片指分配的 chunk 因为对齐和元数据而大于请求大小。

举个例子，程序反复分配和释放 10~100 字节不等的对象，没有规律，长时间运行后，堆里散落着大量几十字节的空闲块。如果这时候需要一个 1MB 的缓冲区，malloc 找不到连续空间，只能通过 mmap 重新向操作系统要内存。RSS 持续上涨，看起来像是泄漏，实际是碎片在作怪。

更麻烦的是，碎片率会影响缓存友好度。对象散落在各处，遍历链表时 Cache Line 反复缺失，性能自然上不去。自定义分配器的核心价值之一，就是把“频繁分配的小对象”集中到一片连续内存里，既减少碎片，又提升局部性。

3. 从 std::allocator 说起：为什么默认不够用

3.1 allocator 接口到底规定了什么

C++ 标准库容器默认使用 std::allocator，它只是对 operator new 和 operator delete 的一层封装。它的接口设计很有意思，不是简单的 allocate 和 deallocate 两个函数，还包含 value_type、rebind、construct、destroy 等一堆约定。这些约定是为了让同一个 allocator 模板能服务于不同元素类型的容器内部节点。

以 std::list 为例，你写 std::list<int>，表面上它只需要存储 int，实际上每个节点是一个包含 next/prev 指针和 int 的内部结构体。list 不能直接拿 std::allocator<int> 来分配节点，它需要 std::allocator<int>::rebind<_List_node<int>>::other，把分配器“重绑”到节点类型。在 C++11 之前，你需要手动提供 rebind，C++11 之后 allocator_traits 会帮你自动推导，但很多老旧自定义 allocator 依然栽在 rebind 上。

allocator 还必须满足一些隐式约定：两个 allocator 对象比较相等时，表示它们可以互相释放对方分配的内存；默认构造的 allocator 必须能释放另一个默认构造的 allocator 分配的内存。这些约定看着不起眼，实际编写时到处都是坑。

3.2 自定义分配器必须注意的“元数据”约定

给容器传自定义分配器，真正难的不在 allocate 和 deallocate 的实现，而在于一堆“传播”规则。C++11 引入了 propagate_on_container_copy_assignment、propagate_on_container_move_assignment、propagate_on_container_swap 这几个类型 trait，默认都是 false_type。

它们是什么意思呢？以 std::vector<T, MyAlloc> 为例，如果 vector 发生拷贝赋值，默认情况下新 vector 会使用自己的 allocator 为元素分配内存，而不是沿用源 vector 的 allocator。这本来没什么问题，但如果你希望内存从一个 allocator 实例迁移到另一个实例，并且这两个实例不相等，那么容器必须逐元素拷贝，而不是直接接管内存，否则释放时就会出问题。

我见过一个项目踩过这个坑：自定义 allocator 内部带着一个线程 ID，用来做线程本地缓存。两个 vector 线程间传递时，因为不满足“相等”条件，容器走了逐元素拷贝路径，性能没问题，但调试时很难理解为什么内存没有被迁移。后来通过传播规则和自定义 traits 才解决。所以任何自定义 allocator，建议先把 propagate 相关 traits 和 is_always_equal 明确声明好，哪怕只是写上 using propagate_on_container_move_assignment = std::true_type;，也能规避大量潜在问题。

4. 手写一个可用的内存池分配器

4.1 设计目标与整体布局

光讲理论不够，下面我写一个简化的固定大小内存池分配器。这个分配器的适用场景很明确：对象大小固定、分配释放频繁、生命周期短（比如每帧产生的临时对象）。它解决的核心问题是：避免每一次分配都触发 operator new -> malloc -> 锁竞争 -> 系统调用的完整链路。

设计思路分四步。第一，一次性从堆上申请一大块内存（比如 1MB），这块内存被切成 N 个固定大小的 slot。第二，用 free list 把所有空闲 slot 串成单向链表，分配时从链表头取一个 slot，O(1) 操作。第三，释放时把 slot 重新挂回链表头，也是 O(1)。第四，维护已分配计数，池满时要么扩容，要么返回空指针。

内存布局大概是这样的：

code复制pool_buf (总大小 = slot_count * slot_size)
+--------+--------+--------+--------+--------+
| slot 0 | slot 1 | slot 2 | slot 3 | slot 4 |
+--------+--------+--------+--------+--------+
     ^        ^
     |        +---- 空闲链表节点指向这里
     +------------- 当前 free_list 头

注意，空闲链表是“侵入式”的：每个空闲 slot 的前 8 个字节（64 位）存下一个空闲 slot 的地址。分配出去后，这块内存完全属于用户，链表指针不再有意义。这就是 free list 不需要额外内存的原因。

槽大小和对象大小怎么定？假设对象大小是 S，则 slot_size = (S + alignof(T) - 1) / alignof(T) * alignof(T)，再和 sizeof(void*) 取最大值，保证空闲链表指针放得下。对齐这一点千万不能省，否则某些平台上 SSE/AVX 类型对齐错误会直接崩溃。

4.2 核心代码实现与参数说明

下面我给出一个可直接编译使用的固定大小内存池实现，基于 C++11/14 标准，不依赖平台特性。核心逻辑集中在 allocate 和 deallocate 里。

cpp复制#include <cstddef>
#include <cstdint>
#include <new>
#include <vector>
#include <cassert>

template <typename T>
class FixedPoolAllocator {
public:
    using value_type = T;

    FixedPoolAllocator(std::size_t capacity)
        : capacity_(capacity), free_list_(nullptr), allocated_(0) {
        // 槽大小需要对齐到 alignof(T)，且至少容纳一个指针
        slot_size_ = (sizeof(T) + alignof(T) - 1) / alignof(T) * alignof(T);
        if (slot_size_ < sizeof(void*)) {
            slot_size_ = sizeof(void*);
        }
        // 一次性向系统申请 capacity_ * slot_size_ 字节
        storage_.resize(capacity_ * slot_size_);
        // 把空闲槽串成链表
        char* base = storage_.data();
        for (std::size_t i = 0; i < capacity_; ++i) {
            void** cur = reinterpret_cast<void**>(base + i * slot_size_);
            *cur = free_list_;
            free_list_ = cur;
        }
    }

    ~FixedPoolAllocator() = default;

    T* allocate(std::size_t n) {
        assert(n == 1); // 固定分配器只支持恰好一个对象
        if (free_list_ == nullptr) {
            throw std::bad_alloc();
        }
        void* result = free_list_;
        free_list_ = *reinterpret_cast<void**>(free_list_);
        ++allocated_;
        return static_cast<T*>(result);
    }

    void deallocate(T* p, std::size_t n) noexcept {
        assert(n == 1);
        if (p == nullptr) {
            return;
        }
        // 把槽放回空闲链表头部
        void** slot = reinterpret_cast<void**>(p);
        *slot = free_list_;
        free_list_ = slot;
        --allocated_;
    }

    // 必需的 allocator 接口
    template <typename U>
    struct rebind {
        using other = FixedPoolAllocator<U>;
    };

    bool operator==(const FixedPoolAllocator& other) const noexcept {
        // 固定分配器之间不能互相释放，所以这里保守返回相同实例才相等
        return storage_.data() == other.storage_.data();
    }

    bool operator!=(const FixedPoolAllocator& other) const noexcept {
        return !(*this == other);
    }

    std::size_t capacity() const { return capacity_; }
    std::size_t allocated() const { return allocated_; }

private:
    std::size_t capacity_;
    std::size_t slot_size_;
    std::size_t allocated_;
    void* free_list_;
    std::vector<char> storage_;
};

这个实现有几个地方值得说明。存储用 std::vector<char> 而不是裸指针，是为了享受自动析构，避免自己管理异常安全。allocate 里如果空闲链表为空，直接抛 std::bad_alloc，这和标准库行为一致。deallocate 标记为 noexcept，因为释放操作通常不允许抛异常。

还有一个细节：operator== 的实现。标准库约定，只有两个 allocator 相等时才允许互相释放对方分配的内存。我这个实现用的是“相同 pool 才算相等”，也就是比较底层数组首地址。这样能避免 std::vector 拷贝时误把内存交给不认识的 allocator 释放。有人说可以简单返回 true，这在单 pool 场景可行，但要小心：如果两个不同生命周期、不同容量的 pool 都返回 true，一旦交叉释放就会产生未定义行为。所以保守一点反而更安全。

4.3 接入 std::vector / 自定义容器的步骤

有了分配器定义，接入标准库容器非常简单。直接作为模板参数传入即可：

cpp复制#include <vector>
#include <memory>

// 创建一个容量为 1024 的池对象
FixedPoolAllocator<int> pool(1024);

// 注意：vector 需要 allocator 是可拷贝构造的，所以传参时要拷贝
std::vector<int, FixedPoolAllocator<int>> vec(pool);

vec.push_back(42);
vec.push_back(100);
// ve...

这里有个容易踩的坑：std::vector<int, FixedPoolAllocator<int>> vec(pool); 看起来是把 pool 传进去了，但 vector 内部会拷贝一份 allocator。也就是说，vector 持有的 allocator 和外部 pool 对象的底层 storage 相同，operator== 依然成立，这没问题。但如果你用默认构造的 FixedPoolAllocator 去释放另一个 pool 分配的内存，就会触发 assert 甚至未定义行为。所以这个池对象需要和容器生命周期绑定，最好用 shared_ptr 或者直接在容器构造时传入池实例。

还要提醒一点：FixedPoolAllocator<T> 是固定大小分配器，不适合 std::string 这种会按需扩容的容器。因为 std::string 内部会分配 1 字节、2 字节、4 字节...不同大小的缓冲区，固定 slot 分配器会直接 assert 失败。需要变长分配时，要么把 slot 大小设置成最大可能值（浪费明显），要么换用支持 counter 的分配器（比如 std::pmr::pool_resource）。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

自定义内存分配器这门手艺，坑比想象中的多。我把自己和身边同事踩过的坑整理成一张速查表，方便大家对照排查。

这些坑里，多线程问题最隐蔽。一个 pool 对象同时被多个线程 allocate/deallocate，free_list 瞬间变成竞态条件，严重时直接 segmentation fault。可用的方案是每个线程一个独立的 pool，或者用原子 CAS 操作维护 free_list。CAS 方案性能更好，但实现复杂度高一些，我建议第一版先用 mutex + 线程本地池，稳定后再优化。

5.2 排查工具与实测经验

排查内存问题时，我一般按这个顺序走：先用 AddressSanitizer（ASan）快速抓越界和 use-after-free，再用 valgrind --tool=massif 看堆内存快照。ASan 对性能影响大，适合测试环境；Massif 能输出内存分配的“山峰图”，能直观看到哪个调用点分配最多内存。

实测中发现一个规律：默认分配器在小对象场景下，单线程也有 20% 左右的额外开销，多线程场景下这个数字会放大数倍。换成自定义内存池后，分配本身降到了几个纳秒的水平，基本可以忽略不计。但代价是代码复杂度上升，你需要管理池的容量、生命周期、线程安全，这些成本对于小项目可能得不偿失。

所以我给新手的建议很明确：先在 profiling 工具里确认热点确实在内存分配，再考虑自定义分配器；如果只是要一个开箱即用的高性能分配器，可以先用 jemalloc 或 mimalloc，替换的性价比非常高。自定义分配器适合那些对象生命周期规律明显、分配模式可控的场景，比如游戏引擎的实体组件、网络协议的消息收发、图形引擎的每帧临时数据。

最后分享一个我自己的习惯：任何自定义 allocator，第一版一定要加 static_assert。比如 static_assert(alignof(T) <= alignof(std::max_align_t), "over-aligned type"); 能挡住 90% 的对齐问题。另外，测试时永远用 ASan 跑一轮再上生产，这能省去大量深夜 debug 的时间。