需自定义内存分配器以规避系统堆的锁开销与碎片问题，提升高频小对象分配性能；简易定长池用预分配+自由链表实现O(1)分配；多尺寸池仿slab分层管理；集成标准容器需满足分配器规范并确保异常安全。
为什么需要自定义内存分配器
默认的 new 和 delete 依赖系统堆管理（如 malloc/free），每次调用都涉及锁、元数据维护和碎片整理，在高频小对象分配场景下开销显著。比如游戏引擎每帧创建数百个临时粒子、网络服务中大量短生命周期的请求上下文，频繁堆操作会成为性能瓶颈。自定义分配器通过预分配大块内存、固定大小对象复用、无锁设计等方式绕过系统堆，把分配/释放降为指针偏移或位图查找，速度可提升数倍至数十倍。
简易定长内存池实现要点
适用于对象大小固定、生命周期集中（如 vector
- 启动时用 operator new 一次性申请一大块原始内存（如 64KB），按对象大小切分为等长槽位
- 用指针数组或单向链表记录空闲槽位地址（头插法入栈，O(1) 分配）
- 构造对象用 placement new，析构后仅将地址归还自由链表，不调用 operator delete
- 避免跨线程竞争：每个线程独享池，或用原子指针+CAS实现无锁自由链表
支持多尺寸的内存池（如 slab allocator）
当对象类型多样但尺寸有限（如 32B / 64B / 128B 几种规格），可仿照内核 slab 分配器分层管理：
- 顶层按尺寸分类：为每种常用 size 维护独立的内存池（slab cache）
- 每个 slab cache 管理若干页（page），每页划分为固定数量的对象槽
- 空闲页回收策略：全空页可返还给系统；半满页保留在 cache 中，减少反复申请/释放开销
- C++17 起可通过 std::pmr::polymorphic_allocator 统一接入标准容器（如 std::pmr::vector
），无需改写业务逻辑
与标准库容器集成的关键细节
让 vector、unordered_map 等自动使用你的分配器，不是简单传模板参数就完事：
立即学习“C++免费学习笔记（深入）”；
- 分配器需满足 C++ 分配器要求：定义 value_type、allocate/deallocate、construct/destroy，并提供 rebind 模板别名（C++17 后可用 using other = MyAllocator）
- 容器内部可能用同一分配器分配控制块（如 map 的红黑树节点）和元素，确保所有内存都走池化路径
- 注意异常安全：若 allocate 失败应抛 std::bad_alloc；construct 抛异常时，deallocate 必须能正确清理已分配但未构造成功的内存
- 调试阶段建议加统计钩子：记录分配次数、当前使用量、最大驻留，便于定位泄漏或池大小不合理
