内存分配器性能对比：对象池、Arena与malloc的真实较量

先放一个结论放在开头，可能跟很多人想的不一样：关于自定义分配器的性能对比，网上能找到的benchmark很多都做得不太走样，一个循环里先new一万次再delete一万次，然后得出结论——malloc真慢，手写池真快。这个结论放到真实业务里基本没有参考价值。我这两年被分配器问题折腾过不少次，也陆续手写过对象池、Arena、大小分类分配器，跟glibc的malloc、jemalloc、tcmalloc都做过比较细的对比测试。这篇文章把测试方法、踩过的坑和几次有代表性的数据结果整理出来，希望能帮你少走点弯路。

1. 先别急着否定malloc：性能对比的真实坐标

1.1 单线程小循环测试的甜蜜陷阱

很多人对malloc的抱怨来自一个特别典型的小测试：单线程、固定大小、连续分配再连续释放，然后跟自己的池化分配器对比，得到“人肉分配器快十倍”的结论。这个测试其实有一个巨大的隐性前提——分配器每次都能从无锁的路径拿到内存，而且分配之后马上释放，所有内存都在热缓存里。

glibc从2.26版本开始引入了tcache，每个线程维护自己的小块内存缓存，取内存和还内存大多数情况下根本不进入arena的锁区域。我拿一台跑Linux 5.15、glibc 2.35的机器做过一次比较简单的循环：单线程，每次分配128字节，分配一万次后全部释放，再重复100轮取中位数。malloc单次op大约在80纳秒上下，如果自己写一个简单的对象池，单次分配加释放能做到20纳秒以内。看起来确实是池快，但你注意一个前提——每轮分配的块数完全一样，释放时机完全集中，这跟真实业务的分配模式差很远。

真实服务里的分配模式往往是分配大小不固定、生命周期长短不均、跨线程释放交错混合。一旦进入这种状态，malloc的tcache命中率就会下降，arena锁竞争开始暴露，这时手写分配器才有机会体现优势。所以第一步不是急着写池，而是先想清楚：你的业务分配模式，到底落在哪个形态里。

1.2 malloc真正值钱的地方：通用性和局部性管理

malloc在大多数场景下没有被替换，不是因为它快，而是因为它足够通用。它管理的是任意大小、任意顺序、任意生命周期的内存块，并且能通过brk和mmap的组合，在内存紧张的时候真正把页归还给操作系统。

还有一个很多人容易忽略的点：malloc在分配顺序连续的对象时，天然保证了它们的内存空间是接近的。你连续new一百个结构体，它们在堆上的位置大概率是连续的。这种顺序分配带来的缓存局部性是隐含福利。自定义池如果做成了“每次分配返回最新释放的那个块”，释放顺序一旦跟分配顺序不一致，就会产生地址跳跃，缓存命中率反而可能下降。这是我在一次高吞吐网关项目里实际碰到的情况——用了对象池之后，平均延迟没变好，P99反而变差了，查到最后就是局部性碎掉了。所以做性能对比的时候，不能只看分配器本身的开销，还得看它对业务内存访问模式的连带影响。

1.3 自定义分配器的不可替代之处：批量生命周期回收

那自定义分配器还有没有存在的必要？有，而且价值非常大，但价值点不在“每次分配少花几十纳秒”，而在“利用业务生命周期做批量回收”。

举个例子，一个游戏服务器每个帧会创建大量临时对象，帧结束之后这些对象全部不再使用。如果让malloc逐个释放，它要反复操作链表、合并相邻空闲块，还要考虑tcache的容量限制。但如果用一个Arena分配器，帧开始时把游标指到起始位置，帧结束后只需把游标重置，一次操作回收一整帧内存。省掉的不只是“释放”的耗时，还有释放时触发的内存整理和元数据写入。

同理，连接池、会话管理、RPC请求上下文这类“按请求/按会话分配和释放”的业务，用对象池或者Arena可以做到分配释放都不碰锁、不碰系统调用。这才是自定义分配器的核心价值所在。性能对比也应该围绕这个“生命周期匹配”来设计，而不是简单比谁在纯分配场景里跑得快。

2. 几种主流自定义分配器的实现原理与适用范围

2.1 对象池：复用自由链表，成本最低收益最直接

对象池是最常见、也最容易写过头的一种。核心思路是：预先分配若干个固定大小的块，用单向链表串起来。分配时从链表头部取一个节点，释放时把这个节点重新挂回链表头部。整个过程不涉及系统调用，也不涉及任何锁（单线程或线程局部线程安全的情况下）。

一个极简的实现长这样：

cpp复制template <typename T>
class ObjectPool {
public:
    explicit ObjectPool(size_t preAlloc = 1024) {
        grow(preAlloc);
    }

    T* alloc() {
        if (!freeHead_) {
            grow(kGrowSize);
        }
        Node* n = freeHead_;
        freeHead_ = freeHead_->next;
        return reinterpret_cast<T*>(n);
    }

    void dealloc(T* p) {
        Node* n = reinterpret_cast<Node*>(p);
        n->next = freeHead_;
        freeHead_ = n;
    }

private:
    void grow(size_t count) {
        size_t bytes = count * kNodeSize;
        char* chunk = static_cast<char*>(::operator new(bytes));
        for (size_t i = 0; i < count; ++i) {
            char* addr = chunk + i * kNodeSize;
            Node* n = reinterpret_cast<Node*>(addr);
            n->next = freeHead_;
            freeHead_ = n;
        }
    }

    struct Node {
        Node* next;
    };
    static constexpr size_t kNodeSize = sizeof(Node) > sizeof(T) ? sizeof(Node) : sizeof(T);
    static constexpr size_t kGrowSize = 1024;
    Node* freeHead_{nullptr};
};

注意这里有个细节：kNodeSize不能直接取sizeof(T)，因为一个空节点至少需要一个next指针。如果T比指针还小，只分配sizeof(T)空间，链表指针会写越界。这部分我后面单独讲，是一个很隐蔽的坑。

对象池的优势很明显：分配和释放都只是几条指针操作，延迟极低。缺点是池中每个块的大小固定，无法动态适配不同大小的对象。如果要支持多种大小，要么为每种大小单独建池，要么在池里分档位。

对象池适用的业务形态是：对象数量上限可预估，并且频繁地“创建后使用、使用后释放”，比如网络服务器里的缓冲区、数据库连接对象、游戏里的实体组件。对象数量如果完全不可预估且持续增长，对象池会不断扩展内存，最终比malloc更浪费。

2.2 Arena：顺序分配的极致，但只有一个动作是免费的

Arena的核心是一大块连续内存加一个游标。分配时直接挪游标，释放时不做任何事情——整个Arena只在reset的时候一次性清空。

cpp复制class Arena {
public:
    Arena(size_t reserveSize = 64 * 1024 * 1024) {
        addBlock(reserveSize);
    }

    void* alloc(size_t n) {
        n = alignUp(n, 16);
        if (curPos_ + n > blockEnd_) {
            addBlock(std::max(n, kBlockSize));
        }
        void* p = curPos_;
        curPos_ += n;
        return p;
    }

    void reset() {
        // 只保留第一个block，也可以全部保留在vector里
        curPos_ = blocks_.front();
        blockEnd_ = blocks_.front() + kBlockSize;
    }

private:
    void addBlock(size_t size) {
        char* block = static_cast<char*>(::operator new(size));
        blocks_.push_back(block);
        curPos_ = block;
        blockEnd_ = block + size;
    }

    static size_t alignUp(size_t n, size_t align) {
        return (n + align - 1) & ~(align - 1);
    }

    std::vector<char*> blocks_;
    char* curPos_{nullptr};
    char* blockEnd_{nullptr};
    static constexpr size_t kBlockSize = 64 * 1024 * 1024;
};

Arena的分配速度是几种方案里最快的，因为它没有链表操作，没有分支，只需一个指针比较加一个指针加法。我实测过，单线程下分配128字节块的耗时可以压到10纳秒以内，比对象池还要快。

但Arena有一个严格的限制：它只能支持“后进先出”的释放语义，或者干脆不支持单独释放。如果你在Arena里分配了对象A，又分配了对象B，你想在B之前单独释放A所占的内存，做不到。唯一的办法是整体reset。这不是Arena的实现缺陷，而是设计哲学——它把“按块释放”这个问题彻底绕开了，代价是只能适配生命周期整齐划一、可以批量终结的场景。

最典型的就是游戏引擎的帧内存。每帧开始切换一个Arena，帧渲染期间所有临时对象都在里面分配，帧结束直接reset。RPC处理的上下文、请求处理的一次性对象也很适合。反过来，如果业务里的对象生命周期参差不齐，Arena基本不可用，硬用的话内存消耗将是灾难级的。

2.3 大小分类分配器：手写tcmalloc？想清楚再动手

大小分类分配器是对象池的复杂版。它把内存分成若干个固定的“尺寸类别”，比如8、16、32、64、128字节一档，每个档位有一个独立的空闲链表。分配时按请求大小就近取整到档位，从对应链表取块。释放时根据指针地址反查它属于哪个页、哪个档位，挂回对应链表。

这就牵涉两个核心问题：一是如何在释放时快速查到块的大小类别，二是如何跨线程共享空闲链表。前者通常用页表索引解决——把内存按页（比如4KB）划分，每一页属于一个类别，用一个全局数组记录页到类别的映射。后者要么用全局锁，要么用线程局部缓存。一个支持多线程并且带TLS缓存的大小分类分配器，体量很容易写到一千行以上。

我的建议是：如果没有十足的把握，别自己从头搓一个完整的大小分类分配器，直接用jemalloc或者tcmalloc，效果比自己写的更好。理由很简单，这两个库在thread cache、空闲链表排序、NUMA感知、内存碎片整理上做了非常多年的优化，普通手写版本很难在“通用场景”下跑赢它们。让我把这句话再说得更直白一点：在通用分配性能上，你最大的对手不是malloc，而是jemalloc这类工业级分配器。如果你只是想提升malloc的默认表现，最省力的路径是链接一个jemalloc，而不是自己写一万行代码。

2.4 第三方库 vs 手写池：我先建议你干什么

拿今天常见的选项来排个序：

我通常给团队的建议是：第一步，先去压测现有malloc在真实场景下的表现，别凭感觉替换；第二步，用jemalloc做一个A/B实验，看收益是否达到预期；第三步，如果jemalloc已经解决大部分问题，手写分配器基本就不必了。只有当你明确识别出“业务生命周期批量回收”的机会，手写对象池或Arena才有足够理由。

3. 测试样本怎么设计：分配序列、并发模型与指标选择

3.1 分配释放序列决定结果，先定义清楚业务形态

做性能对比最容易犯的错，是用一个不相干的测试序列去评判分配器。我见过有人拿固定128字节、先分配一万个再释放一万个的benchmark，去推荐数据库连接池的分配器方案，这根本是错位的。分配释放序列必须反映真实业务形态。

我一般把业务形态归纳成三种模子：

• 瞬时批量型：一段时间内疯狂创建对象，到达某个边界后全部释放。游戏帧、请求批量处理就属于这种。
• 持续稳定型：分配速率和释放速率大致平衡，对象长期在池里流通。网络连接、会话管理、消息队列属于这种。
• 突发尖峰型：平常量不大，特定时间点出现分配高峰，高峰过后内存水位逐步回落。电商大促的订单处理、秒杀系统的请求处理属于这种。

针对不同形态，测试序列要分别设计。瞬时批量型直接测峰值分配速率就够了；持续稳定型要模拟一批对象长期驻留、一批对象高频轮换；突发尖峰型则要在某个时间点突然增大分配量，然后逐步释放，重点观察内存水位的上升和回落。

3.2 多线程模型：TLS、锁中心化、还是跨线程搬运

多线程下的分配器表现，很大程度上取决于锁策略。malloc的tcache是无锁的，但tcache miss之后进入arena共享结构就有锁了。对象池如果做全局free list不加锁，多线程直接用就崩了。常见的处理方式有三种。

第一种，线程局部缓存（TLS）。每个线程持有自己的free list，分配和释放都在本线程的链表里操作，完全不碰锁。问题在于线程间对象迁移——线程A分配的对象，线程B释放时，不能直接挂回线程A的链表，否则需要跨线程同步。通常做法是先挂到一个“中心列表”，再由所属线程或下一个分配周期把它搬回本地。

第二种，全局列表加原子操作。用一个无锁的单向链表，所有线程通过CAS竞争头部。这种方式实现简单，但在高并发下CAS竞争会很激烈，性能随线程数增长迅速恶化。我测过一个8线程直接用全局CAS的版本，分配耗时比malloc还慢3倍。

第三种，每个线程一个池，跨线程对象通过队列传递。这种模式跟业务强相关，比如一个线程只负责生产对象，另一个线程只负责消费释放，两者之间通过无锁队列交换指针。对应到真实系统里，就是“单生产者单消费者”模型，性能可以做到非常漂亮，但对业务结构的要求很高。

测试时建议把这三种模型分开测，不要笼统地说“对象池快不快”。对象池的真实性能，取决于你在多线程下选用了哪种并发策略。

3.3 指标只报平均值没有意义，P50/P99/内存都要看

分配器性能对比只报“平均分配耗时”是我特别不认可的做法。平均值掩盖了两个关键信息：一是长尾延迟，二是内存占用。

长尾延迟在实时系统里尤其重要。像游戏服务端、高频交易系统、视频直播网关这类对延迟敏感的程序，P99和P999往往比平均值更关键。malloc在分配大块内存时可能触发mmap系统调用，单次耗时跳到几十微秒甚至上百微秒，这个波动对平均值的影响不大，但会造成偶发的操作卡顿。手写池如果没有系统调用路径，尾延迟会非常平。

内存占用方面，至少要看三个值：峰值常驻内存RSS、虚拟内存VAS、分配后的碎片率。一个分配器即使速度再快，如果峰值RSS是malloc的3倍，很多业务也接受不了。尤其是容器化部署后内存上限是硬约束，分配器过度预留内存的问题会被直接放大成OOM风险。

3.4 一个可复用的Benchmark框架骨架

我会用一个小框架来支撑对比测试，把操作序列、线程数、大小分布、统计指标都参数化。核心思路不复杂，关键是固定各种变量。下面是一个极简的骨架：

cpp复制struct BenchConfig {
    size_t threadCount;
    size_t opsPerThread;
    size_t allocSize;
    int allocPattern;   // 0=先分配后释放; 1=交错分配释放; 2=随机释放
    bool measureVmem;
};

struct BenchResult {
    double avgNs;
    double p50Ns;
    double p99Ns;
    double p999Ns;
    size_t peakRss;
};

template <typename Alloc>
BenchResult runBench(const BenchConfig& cfg, Alloc&& alloc) {
    std::vector<std::thread> threads;
    std::vector<BenchResult> perThread;
    for (size_t t = 0; t < cfg.threadCount; ++t) {
        threads.emplace_back([&, t] {
            // 记录线程起始时间
            // 根据allocPattern构造分配释放序列
            // 逐个执行alloc/dealloc
            // 记录线程内统计
        });
    }
    // 合并统计，取中位数/百分位
    return merged;
}

实际跑的时候有几个要注意的点。首先是预热，分配器第一次使用时要建立arena、分配初始块，这些冷启动开销不应当计入选型决策；其次是每个线程要跑多轮，轮与轮之间打乱内存释放顺序，避免测试结果依赖某种固定的地址分布；最后是多组配置之间要用相同的内存对齐方式，否则对齐大小不同会导致公平性丧失。

还有一个非常容易被忽略的点：操作系统层面的缺页。第一次触碰刚从系统申请来的内存页时，会触发缺页中断，这个开销比分配器本身的耗时高一两个数量级。所以如果是公平对比，必须让预分配的内存页先全部touch一遍，不然测出来的数据里混进了大量页错误成本。

4. 一次实测的数据复盘：快在哪、慢在哪、为什么逆转

4.1 单线程小对象：池化赢在省系统调用，但赢得很有限

我把一次压测记录的典型数据整理出来，说明问题。测试环境是一台8核虚拟机，Linux 6.2，glibc 2.37，对象大小为128字节，单线程执行先分配再释放，连续跑20万次，重复10轮取中位数。

这个结果符合直觉，池化和Arena确实快。但注意一点：P99差距看似大，实际差值是250纳秒级别，在绝大多数业务里无感。真正能拉开数量级的是高频场景，比如单线程每微秒做几十次分配，或者分配器调用发生在热路径的循环里。

值得注意的反而是峰值RSS。对象池和Arena预分配了8MB以上，而malloc只有4.8MB。如果业务内存本身受限，这个差异反而让自定义分配器处于劣势。所以我说“赢得很有限”指的就是：纯分配性能上池子赢了，但赢的幅度并没有大到可以忽略它对内存占用的负面作用。

4.2 多线程场景：锁设计的分水岭

同一台机器上把测试改成8线程并发，每个线程各分配10万次、释放10万次，记录全局汇总后的平均耗时和P99：

这组数据说明一个问题：对象池在8线程下快不快，完全取决于锁策略。TLS无锁版本的平均耗时只有malloc的五分之一，但全局CAS版本反而比malloc更慢。Arena单锁版本的分配操作不需要锁，因为游标移动是线程私有操作，但如果多线程共用一个Arena，你必须在reset时做线程同步，这个设计在很多场景下会让多线程Arena几乎不可用。

跨线程释放是现实世界里躲不开的场景。一个线程创建任务对象，丢给工作线程，工作线程处理完后释放，这种模型下“TLS无锁完美性能”并不成立，必须走中心列表或跨线程队列。从44纳秒涨到89纳秒，仍然比malloc快一倍，但你已经要为“跨线程所有权转移”付出代价。设计分配器时就要把这条路径想清楚，别等到上线了才发现每次释放都跨线程。

4.3 分配大小分布改变时，malloc反超的场景出现了

前面所有对比都建立在固定128字节这种“小对象温床”上。换成分大小分布，结果会非常不一样。我模拟了一个混合分布：60%的分配是128字节、20%是4KB、15%是64KB、5%是2MB，单线程跑交错分配释放，不采用任何池化策略的malloc和对象池做对比。

对象池在这种场景下其实没法单独工作，因为你不可能为2MB的块单独池化（除非专门建一个大块池）。正常做法是对象池只负责小于等于128字节的分配，超出的大小回落给malloc。于是实际表现变成了：

你会发现一个反直觉现象：纯malloc在混合大小场景下反超了简单的“对象池+fallback”。原因在于，fallback到malloc的大块分配触发了mmap，而mmap系统调用的开销占了主导；你池化的那部分128字节节省的时间，被大块分配的额外开销稀释掉了。反观Arena，它最大的优势是无论分配多大的块，都只移动游标，不触发系统调用，所以在混合大小场景下表现稳定。

这给我们的启示是：对象池解决不了“大小不均”的问题，Arena才是真正跟malloc错位竞争的手写方案。如果你业务里对象大小跨度很大，又不方便分区管理，那还不如换jemalloc。

4.4 P99/P999对比：尾延迟差的本质是分配路径的复杂度

把延迟分布拉出来看会更有意思。malloc的P99之所以偏高，核心原因是分配路径长、分支多：先查tcache，没命中就进arena，arena里要按大小找到对应bin，操作空闲链表，还可能触发sbrk扩张或mmap系统调用。这条链路上任何一个环节出现竞争或系统调用，单次延迟就会暴涨几个数量级。

手写对象池和Arena的分配路径非常短：对象池是判空、链表头替换，Arena是指针比较和指针加法，不存在系统调用，也没有分支缺失的代价。因此在P999这种极端场景下，池化分配器的优势比平均值更明显。我实测的P999数据里，malloc达到4.2微秒，TLS对象池只有0.8微秒，差距是5倍。

对业务的意义在于：如果你系统的瓶颈不是平均延迟而是偶发卡顿，那自定义分配器带来的收益会比你预想的大很多。一个直播网关如果每几分钟出现一次毫秒级的内存分配卡顿，播放端就会感受到一次明显的音画不同步。这种卡顿很难在平均耗时指标里看到，只有盯着尾延迟才能发现。

5. 接入业务代码时的坑与选型经验

5.1 对齐和重绑定这两个C++分配器接口的暗坑

给C++标准容器接入自定义分配器，表面上只需要提供allocate和deallocate，但有两个细节会坑到你怀疑人生。

第一个是对齐。operator new保证返回的内存满足alignof(std::max_align_t)，一般是16字节对齐。但你手写的对象池按sizeof(T)切块，如果T是double，自然对齐到8字节就够了；如果T是带有alignas(32)的类型，或者std::vector<double>里的连续存储，分配的内存必须保证32字节对齐，否则加载指令直接触发段错误。简单粗暴的做法是统一按alignof(std::max_align_t)对齐，至少16字节起步。对象池的kNodeSize里除了要满足“不小于指针大小”，还要把对齐字节数也考虑进去。align_up(sizeof(T), alignof(T))才算安全。

第二个是rebind。标准容器在需要分配其他类型的时候，会通过std::allocator_traits调用rebind，比如std::list<T>内部要分配链表节点，vector要分配元素数组。如果你只写了allocate(size_t n)，没有通过模板方式支持其他类型，容器可能编译不过，或者退回到错误的分配路径。正确处理是让分配器模板化成PoolAllocator<T>，并提供template <typename U> PoolAllocator(const PoolAllocator<U>&)转换构造。这个坑在std::map这种节点式容器上最容易暴露。

5.2 free没有大小参数，块大小追踪别用魔法值

对象池的dealloc(T* p)接口里没有块大小信息，全靠指针本身反推。所以池子必须能在常数时间内确定一个指针属于哪个块、哪个档位。小型对象池的做法是：把每个池子限制在固定块大小上，指针只需要跟预分配块的起始地址比对一下，就能算出它在池内的偏移。多个池子并存时，一般要一个指针到池的映射表，或者用高位地址段区分。

这里出现的一个实践问题：当对象池扩展多次、地址区间不连续，简单的“基址加偏移”就会失效。你需要维护一个地址区间列表，释放时遍历查找，这个查找必须是O(1)或接近O(1)。常见做法是按页索引，每页记录所属池的指针，释放时用地址除以页大小得到页号，查表即得池指针。这段代码看起来不起眼，但一旦漏了，就会在跨越多个chunk时出现“把A池的块还回B池”的严重内存错误。

所以我的建议是：在项目早期给池子加一个调试模式，释放时校验指针是否属于当前池。这个校验在release版本里可以用宏开关关掉，但debug版本一定开着，能救你很多次。

5.3 内存不归还：虚拟内存膨胀的账要算清

手写池和Arena最常见的问题是预分配内存只增不减。对象池增长后，即使业务流量降下来了，那些chunk还留在池里，因为没有机制把它还给操作系统。Arena也一样，你预分配了64MB，实际只用了20MB，剩下44MB虽然在业务层面“没用”，但虚拟内存已经占上了。

要区分虚拟内存和物理内存。纯预分配但未touch的chunk，RSS不会涨，虚拟内存会涨。对很多容器平台来说，虚拟内存限制往往存在，只是阈值比较宽松；如果平台非常严格，这个预分配行为会在流量尖峰时直接触发OOM。另一个问题是进程退出前的释放：如果你的池用static对象持有，析构顺序稍有差池，就可能在使用点之后释放内存，产生use-after-free。我自己习惯于把池做成显式生命周期管理的栈对象，不放在全局静态区。

如果确实需要归还内存，可以给对象池增加“收缩”机制：定期检查空闲链表长度，超过某个阈值就把多余的chunk归还给operator delete。这个逻辑要小心，因为归还时不能把正在使用中的块一并释放。做得不好不如不做，直接定期reset整个池子，让上层业务在低峰期接受一次“内存水位下调”。

5.4 我的选型判据：什么时候用、什么时候坚决不用

综合这些测试和实际工程经验，我给自己定了一套选型判据，供你参考。

对象大小固定、分配频率高、对象生命周期短且齐平，优先考虑对象池。典型例子是网络接收缓冲、消息结构体、游戏中的弹幕和技能特效。Arena适用于“一帧一批”的生命周期模型，比如RPC请求处理、图像处理管线的中间结果、游戏帧内存。对象大小跨度大、生命周期不齐平、分配和释放线程不一致，不要手写分配器，直接换jemalloc，省下来的时间足够你干别的。

还有一种坚决不用的场景：业务里对象数量非常小，每秒分配次数不到几千次，这时候手写分配器引入的复杂度远超收益。我见过一个项目为了一个每秒只调用几百次的日志对象写法，引入了一个带线程局部缓存的对象池，最后定位线上问题时，多线程释放中的偶发段错误让他们排查了整整三天。分配器优化必须建立在实测数据支撑的业务痛点之上，而不是为了优化而优化。

在给标准容器接入自定义分配器时，还有一点提醒：C++的std::allocator_traits在C++17之后要求分配器必须是可拷贝的、无状态的或者状态可复制的。一个持有池指针的有状态分配器，复制到另一个容器时，池指针也必须跟着复制，否则两个容器会共用同一个池。这通常没问题，但如果池的生命周期短于容器，就会产生悬垂引用。我需要不厌其烦地再说一遍：分配器本来就是一个底层基础设施，它的生命周期必须明确地长于所有使用它的对象。

这些内容我自己在实战中也是一步步踩过来的。测试做了无数轮，最后发现最关键的往往不是那个分配更快，而是它跟业务的贴合度、它的生命周期模型是否能无缝融入现有架构。先看业务形态，再决定要不要用、用哪种，别一上来就埋头写池。