两个月前我在优化一个某游戏项目的服务端帧循环时碰到一个很典型的诡异问题逻辑代码里明明没有明显热点CPU占用却始终压不下去。用性能分析器抓了一圈最后的矛头齐刷刷指向分配内存的调用——malloc 和 free 的调用次数不算夸张可耗时就离谱。查了下内部状态发现长时间运行后进程的内存碎片化已经相当严重而且多线程并发分配时还会频繁撞上同一个内存管理的内部锁。那一次之后我彻底认了一件事默认分配器在通用场景下很稳但在高强度、长生命周期、局部性敏感的程序里真的会成为隐形瓶颈。所以就有了这轮自定义分配器性能对比。我把几种常见的自定义分配器逐一实现或改造放到真实工程负载下跑了一遍想弄清楚一件事它们到底比默认分配器快多少、省多少、又贵在哪。这篇东西就是我做完这轮对比后的完整记录包括每种分配器的原理、实现要点、测试设计以及最终的数据和选择建议。适合正在做游戏引擎、服务端中间件、高频交易系统这类性能敏感项目的开发者参考。1. 为什么默认分配器不够用了——我决定自己做对比的起因1.1 从一次游戏服务器卡顿开始的排查当时我手上的项目是一个模拟类游戏的后端服务里面大量使用全局消息对象和事件对象每个帧循环都要创建、分发、销毁几千个小型对象。这类对象的生命周期很短往往在一个函数栈内就完成了使命。最初我用普通的new/delete开发期没觉得有问题等接入长时压测后就开始露馅了。我先是用采样性能分析器抓热函数发现 malloc 和 free 相关调用占了大概 12% 的 CPU 时间这已经是一个很可观的数字了。进一步跟踪发现问题不只是分配慢还有两个隐藏因素小对象频繁分配释放导致堆上小块内存越切越碎后续分配不得不做更多的空闲块合并与遍历。服务端开了 8 个工作线程多个线程同时进入分配器的内部临界区时锁竞争让分配耗时的波动特别大。压测输出里偶尔会出现一条 10ms 的尖峰排查到最后基本都落在内存分配上。我当时第一反应不是立刻换分配器而是先统计了对象的大小分布和生命周期因为这一步直接决定了之后选用哪种自定义分配器。统计结果很清晰90% 以上的对象小于 64 字节且生命周期几乎是创建后立刻用用完立刻弃没有跨帧驻留的情况。这种负载特征恰恰是自定义分配器最容易发挥价值的区间。1.2 默认的 malloc/new 到底慢在哪很多人印象里malloc就是从堆里切一块内存给我底层应该很快。但如果你看一下主流默认分配器的实现机制——拿最常见的 glibc malloc 举例——会发现它夹杂了大量通用性设计这些设计在极端场景下会变成负资产。分配器要维护多个不同大小类别的空闲链表还要做动态大小分类、空闲块合并、分割、状态标记。多线程环境下需要用多个内存管理区arena来缓解竞争但 arena 数量有限线程数一多竞争还是会出现。每次分配返回的地址没有保证连续性分配次数多了以后活跃对象散布在堆的各个角落CPU 缓存的局部性会被严重破坏。malloc 本身是 C 库函数为了保持 ABI 兼容还承担了很多审计、对齐、簿记等元数据逻辑这些都是实打实的额外开销。用生活里的事情来类比默认分配器就像一个大型仓储中心什么货物都收什么包装都拆还要给每件货物打标签、做登记、定期盘点。你只是想让一批周转极快的临时物料快速进出库但这个仓储系统为了什么都能存每一步都得走完整流程自然快不起来。当然我不是说默认分配器不好。它最大的优点恰恰是通用和稳定在大多数业务程序里完全够用。问题只在于当你明确知道自己的分配模式、分配大小和生命周期特征时针对性地自定义分配器就能把那些通用逻辑里你不需要的部分全部省掉性能自然上来了。2. 我对比的四种自定义分配器原理与实现要点这轮对比里我选定了四种不同类型的自定义分配器分别覆盖最简单、最灵活、最通用和最并发友好四个维度。它们基本代表了我在日常项目里最常考虑的几个方向。2.1 线性分配器Linear Allocator最快但最局限线性分配器的实现思路是所有自定义分配器里最简单直接的一种也叫 bump allocator。它预先申请一大块连续内存然后用一个水位指针记录当前分配到的位置。分配 N 字节时只需把水位指针向后挪 N 字节并返回原来的位置释放操作基本不做事情唯一真正的回收动作是把水位指针重置回起点一次性丢光所有已分配内存。用文字描述可能还不够直观核心代码大概长这样class LinearAllocator { char* m_base; // 堆区基址 size_t m_capacity; // 总容量 size_t m_offset; // 水位偏移 public: LinearAllocator(size_t cap) : m_capacity(cap), m_offset(0) { m_base static_castchar*(::operator new(cap)); } ~LinearAllocator() { ::operator delete(m_base); } void* allocate(size_t size, size_t alignment 16) { size_t aligned (m_offset alignment - 1) ~(alignment - 1); if (aligned size m_capacity) return nullptr; // 内存耗尽 void* ptr m_base aligned; m_offset aligned size; return ptr; } void reset() { m_offset 0; } };注意这里我特意做了对齐处理。对齐在内存分配里是个很容易被忽略但特别影响性能的细节后文我会专门展开讲。线性分配器的特点是分配操作几乎只有指针加减和一次对齐计算通常能在 1~2 ns 量级完成缓存局部性极好因为分配出去的内存天然是连续递增的后面的分配常常就在上一个对象旁边访问起来很容易命中缓存。缺点是释放操作失控。它不支持单独释放某一个对象只能等一次批量重置。所以它只适合一次性分配大量对象、集体结束后统一释放的场景比如帧循环里的临时对象、编译器的 AST 节点、渲染引擎的临时顶点缓冲等。如果把长生命周期对象放进线性分配器内存会被一直占用到重置为止内存利用率堪忧。2.2 栈分配器Stack Allocator有进有退的折中栈分配器在线性分配器的基础上增加了一个mark/release机制。你可以把当前水位指针保存为一个标记之后任意次数的分配都会被记在该标记之上当这些临时对象不再需要时直接把水位指针回滚到之前保存的标记处就能一次性回收这一段全部内存。我简化后的实现核心如下struct StackAllocator { char* base; size_t offset; size_t capacity; size_t mark() { return offset; } void* allocate(size_t size, size_t alignment 16) { size_t aligned (offset alignment - 1) ~(alignment - 1); if (aligned size capacity) return nullptr; void* ptr base aligned; offset aligned size; return ptr; } void release(size_t marker) { offset marker; } void clear() { offset 0; } };这个标记—回滚模式的价值在于它给分配器带来了生命周期上的灵活性。每当你进入一个作用域或一个处理阶段先做一个标记阶段内所有临时分配都可以在退出阶段时统一回滚释放而不需要像线性分配器那样只能一次清空整个缓冲区。因此栈分配器特别适合分层处理但每层临时对象用完就丢的场景比如递归下降解析器的递归调用栈、或者对一批数据做多阶段流水线处理时每个阶段都可以用一个标记管理自己的临时内存。栈分配器的性能通常只是略低于线性分配器因为每次分配同样是对齐指针位移两步它的主要成本在调用方——你需要发出 mark 和 release 的额外函数调用但这类调用量相对较少总体开销可以忽略。不过它的局限也很明显依然不支持任意顺序的释放。如果一个对象想比同阶段内的另一个对象更早释放栈分配器就无能为力。另外标记回滚释放的内存不会归还给操作系统长期运行的程序需要自行设计缓冲区大小否则可能出现内存占用偏高的现象。2.3 空闲链表分配器Free List Allocator通用型选手空闲链表分配器是经典的自定义分配器方案把所有空闲块通过指针串成链表分配时遍历链表找到一块足够大的空闲块取出或切分后返回释放时把块重新放回链表并尝试与相邻空闲块合并减少碎片。它有几种典型策略first-fit找到第一个大小足够的空闲块就返回速度快但容易把大块切碎。best-fit遍历全部空闲块找最接近需求大小的块内存利用率高但分配开销大。伙伴系统buddy system把内存按 2 的幂分成伙伴块合并只会发生在大小相同的伙伴之间是 free list 的一种特殊形式分配速度稳定。我在实测里实现的是 first-fit 加立即合并的版本每个空闲块头里记录块大小和注入式链表指针。代码层面我并不想在这里全部展开简单示意关键数据结构struct BlockHeader { size_t size; // 块的有效大小 BlockHeader* next; // 指向下一个空闲块 }; class FreeListAllocator { BlockHeader* m_freeHead; // ... };一个很容易踩的坑是内存块头的开销。每次分配返回给用户的地址必须跳过一个 BlockHeader 大小这意味着如果你连续分配大量 8 字节的小对象每个对象实际要消耗 16 字节而且块越多header 开销占比越高。在后面的测试数据里你可以看到free list 分配器的内存利用率并不总是最漂亮的。这类分配器的优点是释放自由度最高你可以任意顺序释放任意对象不需要依赖生命周期的范围同时回收能力远强于线性/栈分配器浪费的内存更少。但代价是每次分配都可能遍历链表分配吞吐明显低一截。在结构上它也更复杂稍不留神就会出现指针悬挂、相邻块合并遗漏等内存管理 bug。2.4 线程本地缓存分配器TLS Allocator并发场景的正解线程本地缓存分配器的设计思路是为每个线程准备一个独立的缓存池线程分配内存时优先从本地池取本地池空了就一次性向底层堆申请一大块释放时则放回本地池。由于每个线程只管自己的池大多数情况下没有任何锁竞争分配吞吐能随着线程数扩展。我实验里的实现参考了常见线程池内存分配器的简化版每个线程用一个线程本地变量持有对象数组池按固定大小类如 8、16、32、64、128 字节分桶管理。分配时按大小选择对应桶从槽位数组里取一个释放时把槽位归还。核心结构大致是这样class TLSAllocator { public: void* allocate(size_t size) { // 超过阈值走 ::operator new小对象走本地槽位 auto local getLocalCache(); return local.alloc(size); } void deallocate(void* ptr, size_t size) { auto local getLocalCache(); local.dealloc(ptr, size); } private: static LocalCache getLocalCache() { thread_local LocalCache instance; return instance; } };这里有几个实现细节我用别的分配的机制做过替代一是批量补充本地池空掉时不是一次只从默认堆拿一个对象而是找系统一次性拿一批比如 64 个对象大小的连续内存放入本地池有效摊薄了向系统堆申请的开销。二是批量回缴本地池缓存对象数量超过阈值时把多余对象整体归还给默认堆避免某个线程长期不出声却持有大量空闲内存。线程本地缓存分配器在并发场景下的优势非常明显我们后面会看到数据。但在单线程或两极线程一个线程狂分配、其他线程很闲的场景里它没有太多额外收益反而因为多了一层缓存管理单次分配的开销可能略高于线性分配器。真正要留意的是内存占用每个线程的本地池都预留了余量线程数越多潜在的囤积内存就越多。所以完整的实现一般都要带一个空闲内存监控和定期收缩机制否则长时间运行的服务端进程可能莫名把 RSS 拉到很高。3. 测试设计为什么对比测试本身也需要较真很多人做性能对比容易犯一个错想都不想就开测然后把数字往外一贴。但内存分配器的性能表现跟你测的负载模式、测试时长、线程数量、对象大小分布高度相关测试设计不严谨得出来的结论往往会误导人。我自己在正式开测前就强制自己回答了三个问题。3.1 我先问了三个问题第一个问题我要比什么指标如果只比吞吐量可能会忽略一个分配器快得离谱但内存耗尽得也离谱的问题。所以我定了四个指标分别是分配/释放吞吐量、峰值内存占用、p99 延迟抖动、以及真实负载下的缓存局部性。第二个问题在什么负载模式下测分配器在不同负载下的表现可能完全相反。比如线性分配器的吞吐可以秒杀一切但你要是让对象存活到第二轮才释放它的内存就会迅速爆掉free list 分配器单线程吞吐垫底但在需要任意顺序释放的模拟器中反而最靠谱。所以我没有只测一种固定模式而是覆盖了单线程、多线程、混合生命周期三类。第三个问题跟谁对比当然要跟默认分配器对比但这里有个细节——不同平台的默认分配器实现差异极大。同一段代码用 glibc malloc 测是 1 倍基线换成另一个平台的默认分配器可能数字差出一大截。所以我在记录结果时特意注明了测试环境和默认分配器的具体版本否则对比结论根本没法迁移。3.2 测试环境和基准方法测试跑在某台 x86_64 的 Linux 服务器上编译器用的 GCC 11 加-O2 -stdc17。默认分配器基线用的是测试机自带的系统堆分配器。为了把系统噪声压到最低我只保留两个 CPU 核做负载并把进程绑核关闭了超线程干扰。计时方法上也讲究了一下。我没有用单次分配一万次取平均这种粗糙做法而是做了这样几件事每轮测试分配次数固定为 100 万次重复 5 轮。每轮里分配的内存块地址完全不连续但分配顺序由随机种子预生成避免顺序分配让某些分配器捡到缓存局部性优势。统计时取 5 轮的中位数而不是平均因为平均值容易被偶发的内核调度尖峰拉高。使用std::chrono::steady_clock记录 wall time。延迟抖动单独测记录 100 万次分配里落在不同延迟区间的次数重点看 p99 和最大值。因为做服务端研发的人都知道平均耗时只是面子p99 或者 p999 才是决定用户体验的里子。3.3 四种基准场景我设计了四个基准场景尽量贴近真实开发里常见的分配模式。场景 A单线程小对象高频分配释放。对象大小在 16~128 字节随机分配后立即释放模拟消息对象和事件对象的频繁创建销毁。场景 B单线程大对象批处理。每次随机分配 2~8 KB 看似较大的对象分几批处理代表纹理上传、批量数据包构造这类负载。场景 C多线程并发分配释放。线程数分别设置为 1、4、8每个线程独立分配和释放自己的对象模拟服务端多个 worker 并发处理请求。场景 D混合生命周期。对象分配后有一部分存活时间较长模拟缓存对象另一部分立刻释放模拟临时变量模拟真实业务中既有长驻内存又有临时内存的复杂状态。每个场景下我都用同一套操作序列分别喂给四种自定义分配器以及默认分配器作为对照。操作序列由一个统一的 trace 生成器产出保证任何分配器收到的分配请求序列完全一致避免因顺序不同导致的公平性争议。4. 性能数据分配吞吐、延迟抖动和内存消耗在展示数据之前先声明一点下面的数字是我在自己搭建的实验工程、特定环境和特定负载模式下得到的相对结果不代表所有机器上都会得到一模一样的数据。但对于判断自定义分配器的收益量级和各自优劣势这个相对变化已经非常能说明问题了。4.1 单线程小对象分配/释放吞吐场景 A 的结果是四种分配器差距最大的一组。以默认分配器为基线 1.0我统计了每次分配释放一对操作的相对耗时换算成相对吞吐倍率如下分配器相对吞吐倍率说明默认分配器1.0x基线线性分配器约 9.8x分配只有对齐指针位移释放近乎零成本栈分配器约 8.1x与线性相差无几额外 mark/release 开销很小空闲链表分配器约 2.3x被链表遍历拖累TLS 分配器约 6.2x本地池命中时很快桶内槽位复用也划算这个结果和直觉一致。真正让我意外的是空闲链表分配器居然连 3 倍都没到仔细分析后发现罪魁祸首是释放时的相邻块合并操作。每次释放都要读取相邻块的 header 判断是否可以合并这在地址离散、反复分配释放的序列下很容易导致额外的 cache miss。更糟的是每次合并成功后链表结构会变化下一次分配的遍历路径都不一样增加了分支预测失败的率。线性分配器和栈分配器在这个场景下几乎已经是理论极限了它们的操作本质上就是加法指令 对齐位运算没有比这更快的分配方案。但我也要强调场景 A 恰好是这两类分配器最舒服的模式——对象立即释放生命周期单一完全符合它们的集体回收设计。4.2 内存碎片与峰值占用吞吐量高不代表内存管理好。场景 A 结束后我统计了每个分配器在整个测试周期内的峰值内存占用结果对比也很明显。分配器峰值内存占用相对默认分配器观察默认分配器1.0相对均衡线性分配器0.9 左右如果一次性分配总量可控反而更省栈分配器0.9 左右和线性类似空闲链表分配器1.4~1.8header 开销 碎片累积TLS 分配器1.5~2.5线程本地池囤积空闲内存这里暴露了两个重要问题。第一个是空闲链表的 header 开销。我们前面提到每次分配返回的用户地址前都要藏一个 BlockHeader当对象只有 16~64 字节时这个 header 白白吃掉一半以上的有效空间。如果你在场景 A 里连续分配 100 万次即使对象最终被释放了分配器内部空闲链表的碎片整理也不一定能及时把小块合并回来峰值内存自然就高了。第二个是 TLS 分配器的囤积问题。每个线程本地桶里都预留了几十条空闲槽位8 个线程并发跑下来底层堆总是反复为各个线程补充内存而这些内存大部分都静静趴在本地池里。最高峰时我观察到 TLS 分配器消耗的内存超过了默认分配器的两倍。好在我在实现里加了空闲槽位超过阈值就整体回缴的收缩机制否则这个数字还要更高。内存并不是越省越好关键看可预测性。线性分配器和栈分配器的内存占用曲线是最可预测的因为它就一块预申请的缓冲区用满就没有了反而是那些能复用的分配器因为要维持内部结构峰值内存的波动幅度特别大。4.3 多线程并发分配伸缩性场景 C 的结果我认为是整个测试里最有现实参考价值的因为现代服务端基本都是多线程内存分配锁竞争是默认堆分配器最被人诟病的点之一。数据我整理成了相对基线默认分配器单线程为 1.0的倍率表分配器1 线程4 线程8 线程默认分配器1.00.850.70线性分配器9.88.06.5栈分配器8.17.26.4空闲链表分配器加全局锁2.30.750.60TLS 分配器6.210.513.8默认分配器在线程数增加时不仅没有提升吞吐反而下降了。它的内部内存管理区虽然做了并发优化但在 8 个线程同时高频分配小对象时锁竞争还是蝴蝶效应般放大了。多线程场景下p99 延迟也被拉得很难看某些分配操作能飙到 300 微秒以上高并发线上环境里这就是卡顿的种子。空闲链表分配器是我自己实现并加了一把全局锁的版本结果是灾难级的线程数越多吞吐越低到 8 线程时快跌到默认分配器的水平之下。这其实也验证了一个常识——通用型分配器必须先解决并发扩展性才能用于服务端。后来我看了些开源项目的做法它们会给每个线程准备独立的 free list或者用无锁链表效果才好一些但复杂度也上去了。TLS 分配器是这一组的绝对赢家线程从 1 涨到 8吞吐从 6.2 倍涨到 13.8 倍。原因不复杂每个线程的分配请求几乎都能命中自己的本地缓存池锁竞争基本消失内存分配变成了一个高命中率缓存访问问题天然具备良好的扩展性。4.4 缓存局部性对真实工作负载的影响场景 D 我采用了一种更接近线上真实情况的做法不测纯分配速度而是把分配融入一个模拟处理流程里。流程模拟的是接收一批网络消息解析后分发到多个对象处理完再释放处理逻辑里会反复读取刚分配对象里的字段再计算结果这样就能反映出不同分配器返回的内存布局对 CPU 缓存命中率的影响。我统计了两个指标处理一帧消息的总耗时以及 LLC最后一级缓存的 miss 率。结果如下分配器单帧处理耗时相对默认分配器LLC miss 相对率默认分配器1.01.0线性分配器0.720.55栈分配器0.790.63空闲链表分配器1.11.05TLS 分配器0.810.72这个结果非常有意思空闲链表分配器明明单项分配速度是默认分配器的 2.3 倍但在真实工作负载里反而比默认分配器还慢一点。原因就在碎片化和对象地址离散化上——你的对象分散在被频繁合并拆分的空闲块之间处理这些对象时CPU 每次读取不同对象几乎都要跨越不同的缓存行cache miss 带来的访存延迟吞掉了分配操作省下来的时间。线性分配器和栈分配器表现最好因为它们分配出去的对象在内存里紧密相邻处理流程顺序遍历时几乎就是顺序扫描缓存行局部性优势一目了然。TLS 分配器也不错虽然每个线程的池是相互独立的但同一线程内的对象地址相对集中缓存友好度比默认分配器高不少。这里我想多说一句很多人在评估分配器性能时只盯着分配函数的耗时忽略了分配器返回的内存布局对整个程序后续访存的影响。其实后者往往影响更大特别是你的对象会被反复读写的时候。这也是为什么线性分配器总是出现在游戏引擎里——游戏对象的更新循环本身就是一种天然的顺序遍历连续内存布局能把缓存效率拉满。5. 从数据到选择不同场景到底该用哪种分配器数据看完了下一步自然是拿它做决策。我把自己在各类项目里总结的选型三角分享一下分配模式决定基本类型并发度决定是否需要线程本地化对象生命周期决定能否使用集体回收。5.1 游戏帧循环场景的选择游戏引擎是自定义分配器最经典的战场。帧循环里每帧都会创建大量临时对象——粒子、碰撞数据、渲染命令、临时变换矩阵——它们都有一个共同特点帧内创建帧末全部销毁生命周期完全一致。这种场景下线性分配器或者带标记回滚的栈分配器就是最合适的。我在自己的实验工程里模拟了一帧的处理流程把粒子系统临时对象全部放进线性分配器帧末调用一次reset()效果立竿见影分配延迟下降了一个数量级而且由于所有粒子数据连续排布粒子更新的缓存命中率也有明显提升。有几点实操经验值得写下来预设缓冲区大小必须算好。你可以先用旧分配器跑一遍真实负载统计一帧峰值对象总字节数然后乘以 1.5 的安全系数作为线性分配器容量。要是出现容量不足不要随便扩容先回头检查是不是有对象跨帧驻留了。跨帧驻留对象千万不能放线性分配器。你只要把一个对象留到下一帧整个分配器就没法整块重置了轻则内存泄漏重则返回悬空指针。帧内嵌套阶段可以用栈分配器的 mark/release 来实现局部集体释放比线性分配器的粒度更细适合帧内分多个子系统处理的架构。5.2 服务端高并发场景的选择服务端的分配模式和游戏引擎很不一样。消息到来时间不均匀对象生命周期长短不一而且工作线程数通常很多。做服务端中间件和服务器底层库时我强烈建议优先考虑线程本地缓存分配器并配合一个周期性的内存收缩机制。我的具体建议是这样小对象一般小于 1024 字节走 TLS 分配器大对象继续走默认堆这样能控制核心内存池的复杂度。给 TLS 分配器加一个后台监控指标当前所有线程的本地缓存总量。当总量超过某个阈值比如每线程 16 MB时触发一次批量回缴。压测时一定要观察长期稳定运行后的 RSS。很多 TLS 分配器实现的通病是运行前期内存平稳运行几小时后因为线程活跃度变化空闲缓存没有及时回收RSS 一截一截往上爬。所以自动收缩不是优化项而是刚需。并发场景下尽量不要用单锁版的全局 free list也不要迷信某个分配器在单线程下的绝对倍数。多线程处理器上真正稀缺的资源是锁和缓存一致性流量任何一次全局临界区访问都会让你前面省下的时间全白费。5.3 我的几点实操教训这轮对比做完以后我把踩过的一些坑总结成几条算是给后来者排雷内存对齐不做好性能会跳水。我在实现线性分配器初期图省事略过了对齐以为反正字节数对了就行。结果分配出去的指针经常是未对齐的对象里的 8 字节int64字段在某些设备上出现 2 倍访存惩罚导致真实负载测试数字很难看。后来老老实实做了alignment参数所有分配都按 16 字节对齐问题立刻消失。记住分配器的第一义务不是快而是返回对齐且有效的指针。分配器测试必须放到生产负载上做第二轮验证。我第一轮用纯分配压力测试得到的数据和第二轮真实业务负载得到的数据排序是不完全一致的空闲链表就是典型例子。原因就在于缓存局部性对真实逻辑有额外影响。没有真实负载验证单看 bench 数字选的分配器很可能坑你。小心分配器之间的转换期。在实际工程里如果从默认分配器切到自定义分配器最稳的做法是先做一段双缓冲切换保留旧分配器接口新分配器以旁路形式同时运行并做交叉校验确保没有越界和泄漏再彻底切换。我见过不少人写完分配器直接全局替换结果对象生命周期没理清线上崩了才回头排查。监控一定要上齐。无论用哪种分配器至少要把 p99 延迟、分配器空闲内存量、系统 RSS 三个指标盯住。很多时候问题不是不够快而是某一条尖峰不可接受或者平峰正常、峰值内存失控。写在最后的一点个人体会是自定义分配器不是银弹更不是所有人上来都应该搞的东西。选择它的唯一理由应该是——你对项目负载做了统计确认默认分配器的通用代价拖累了核心路径并且你愿意承担额外的复杂性和维护成本。如果你的项目只是偶尔分配几个对象或者对象生命周期一点都不规整那随便用默认分配器就完了不值得为了追性能指标凭空造轮子。反过来如果你的负载特征非常明显比如游戏帧循环式的全体短暂生命周期或者服务端多线程高频小对象那么花点功夫把分配器做对带来的收益可能比优化几十处逻辑代码还要大。
