Hang Zhengyang
English ↗

MemoryPool vs ObjectPool：理念、职责与内存安全

这篇文档不讲代码细节，而是从设计理念出发，讲清楚：

  • MemoryPool 和 ObjectPool 各自想解决什么问题；
  • 它们在“抽象层级”上的区别；
  • 为什么当前实现不提供强内存安全保证；
  • 如果想要“更安全”，应该往哪几个方向加约束 / 加封装。

一、两个层次：内存粒度 vs 对象粒度

可以先把这两个组件放到一个“分层图”里：

  • 底层：MemoryPool（按 block 管理原始内存）

    • 不知道类型，只知道：有一堆“大小一致的 block”。
    • 职责：把频繁的 new/delete 变成少量大块分配 + O(1) free list 操作。

  • 上一层：ObjectPool<T>（按对象生命周期管理）

    • 知道类型 T，知道需要调用构造 / 析构。
    • 职责：在固定大小 block 上构造 / 销毁 T，对上层暴露“T* create() / destroy(T*)”语义。

用一句话对比：

  • MemoryPool 的“资源单位”是 内存块（block）；
  • ObjectPool<T> 的“资源单位”是 对象（T 的一次生命周期）。

它们都是“性能基础设施”，但站在的抽象层级不同。

二、从理念看：三种“谁来负责什么”的划分

从“职责划分”来看，可以粗暴地分三层：

  1. 原始内存管理（raw memory management）
    • 谁向操作系统申请大块内存？
    • 谁把这块内存切成小块？
    • 谁知道还有多少可用 block？
  2. 对象生命周期管理（object lifetime management）
    • 谁负责调用构造函数 / 析构函数？
    • 谁保证“构造一次，对应析构一次”？
  3. 所有权与安全性（ownership & safety）
    • 谁保证不会 double free / use-after-free？
    • 谁保证这个指针只在合法的线程 / 时间窗口里被访问？

对应到当前实现：

  • MemoryPool：只做 第 1 层。
  • ObjectPool<T>：做 第 1 层 + 第 2 层的一部分。
  • 第 3 层（强内存安全）：几乎完全交给调用方自己负责。

这就是“为什么你会感觉它们都不太安全”的根源：
它们刻意停在了“性能基础设施”的层级，没有向上继续封装成“强所有权模型”。

三、MemoryPool 的理念：我只负责“块”，不管“谁在里面”

从理念上，MemoryPool 是一个“无类型（type-erased）的块分配器”：

  • 它只关心：
    • 这一块内存大小是否 >= blockSize_；
    • 这块内存在 free list 里还是已经发出去了。
  • 它完全不知道：
    • 这个 block 里现在是不是一个 Foo；
    • 构造函数有没有成功执行；
    • 你是不是已经把它当作别的类型用掉了。

因此，从安全性角度看：

  • MemoryPool 做不到：
    • 检查你是不是忘记调用析构；
    • 检查你是不是跨池释放；
    • 检查你是不是用错类型；
  • 它能做的只是：
    • 不随便访问 block 内部内容；
    • 只负责组织“哪些 block 还空着”。

这有点像 C 语言里的 malloc：

  • 它给你一块“原始内存”；
  • 你愿意把它当 int、double 还是自定义 struct，完全由你决定——也完全由你负责。

设计上的 trade-off 很直接：

  • 优点：实现简单、高效、可复用在各种上层对象/容器；
  • 缺点：类型安全 & 生命周期安全 全靠调用方自律。

四、ObjectPool 的理念：把“对象生命周期”贴在内存块上

ObjectPool<T> 在理念上往上走了一步：

  • 它把 “构造 / 析构 T” 这件事一并接管了：

    void* mem = pool_.allocate();
return new (mem) T(args...);   // create

    obj->~T();
pool_.deallocate(obj);         // destroy

也就是说，它在“块分配器”的基础上做了两件事：

  1. 确保“每次分配对应一次构造，每次回收对应一次析构”（如果你按约定调用 create/destroy）。
  2. 把“用错类型”的风险限制在 模板形参 T 的选择 上（因为一旦确定了 T，这批块理论上只会存放 T）。

但注意，它仍然没有解决：

  • 谁来保证 destroy 一定被调用？
  • 谁来禁止别人 delete obj / free(obj)？
  • 谁来禁止把这个 T* 传到其它线程后乱用？

原因很简单：接口里暴露的是“裸指针 T*”：

  • 裸指针本身不带“所属池是谁”的信息；
  • 也不带“是否已经被 destroy 过”的标记；
  • C++ 语义层面也不会阻止你 delete obj。

所以，ObjectPool<T> 在理念上只是：

在性能和使用习惯之间的一个折中：
比 raw MemoryPool 更方便一点，但仍是“低层工具”，而不是“强安全抽象”。

五、和 malloc/new 相比：默认更快，但也更危险

先把一个现实说清楚：

  • 标准库里的 malloc/new 在现代平台上，通常会配合系统 allocator 做一些防护，例如：
    • 部分越界写会触发 crash（破坏了 allocator 的元数据）；
    • 某些 double free 会被检测出来；
    • 搭配 ASan/Valgrind 等工具，可以比较容易发现 UAF / 越界。

而一个简单的 mempool / objpool 实现往往长这样：

  • 内部只是一个大数组 + 若干指针 / 索引；
  • 分配只是移动 free list / 索引；
  • 释放只是把块挂回 free list，不做额外校验。

结果就是：

  • 越界写：可能只是悄悄改坏了别的对象 / 元数据，很久之后才炸；
  • double free / use-after-free：通常不会被立即检测到，只是让 free list 结构悄悄腐蚀，最终以奇怪崩溃形式出现。

所以可以直接记一句：

pool 技术的默认前提是：用“更少的安全检查”换“更快的分配/回收”。

这不是“实现不够好”，而是这类 infra 组件天然的 trade-off：
想安全，就要加额外结构 / 状态 / 检查；想极致性能，就会主动关掉这些东西。

六、为什么当前实现几乎“没有内存安全保证”

从更严苛的角度看，现在的这套实现有很多潜在 UB 入口：

  • MemoryPool：

    • 可以拿到一个 block，然后忘记析构就 deallocate；
    • 可以把一个 block 当成错误的类型使用；
    • 可以把别处分配的指针错误地传给 deallocate。

  • ObjectPool<T>：

    • 可以在 destroy 之后继续使用 T*（use-after-free）；
    • 可以误用 delete obj; 而不是 destroy(obj)；
    • 多线程下可以竞争访问同一个 ObjectPool<T>；

为什么会这样？

  1. 这是一个“教学 / infra demo”级别的实现：
    • 主要目的是演示 “通过池子复用资源可以提高性能”；
    • 没有刻意把“安全性”作为第一目标。
  2. C++ 本身的类型系统 对裸指针非常宽松：
    • 指针没有“所属池”的概念；
    • 也没有“已经释放/未释放”的状态标记；
    • 运行时默认不做 double free / UAF 检查。

一句话概括：

这套 Pool 更像是“把手动管理内存，集中成一块代码”，
而不是“把手动管理变成自动安全”。

七、mempool / object pool 典型安全问题一览

把上面分散提到的问题按组件收个口：

  • MemoryPool 侧（面向裸内存块）：

    • use-after-free：归还 block 之后继续读写；
    • double free：同一指针多次传给 deallocate；
    • buffer overflow：写出 block 边界，破坏其他 block 或 free list；
    • 对齐问题：用不合适的 blockSize 存放需要更高对齐的类型。

  • ObjectPool 侧（面向对象实例）：

    • use-after-release：destroy 后继续用 T*；
    • 未重置对象状态：复用同一块内存时逻辑字段残留；
    • 多线程重复归还：不同线程竞争调用 destroy 同一个指针。

基础实现往往不主动防御这些错误，只是假设：

“调用方会严格按约定使用。”

如果希望在开发期更容易发现错误，常见手段包括：

  • debug 版本下：
    • deallocate 后用特定字节模式填充（如 0xDD/0xDEAD）；
    • 维护额外的“已分配/已释放”标记表，检测 double free；
    • 在块前后加 canary / guard bytes，检测越界写；
  • 搭配工具：
    • AddressSanitizer / Valgrind / Dr.Memory 等做额外检测。

这些手段本质上是：在 pool 外面再套一层“debug 保护层”。

八、如果想要“有内存安全”，应该怎么做？

要让这套东西更安全，可以从三个方向增强“抽象层”：

1. 用 RAII 封装指针：自己造一个“池智能指针”

思路：不要直接把 T* 暴露给用户，而是暴露一个带析构逻辑的 handle 类型，类似于自定义 unique_ptr：

template <typename T>
class PooledPtr {
public:
    PooledPtr(ObjectPool<T>* pool, T* ptr) : pool_(pool), ptr_(ptr) {}
    ~PooledPtr() {
        if (pool_ && ptr_) pool_->destroy(ptr_);
    }

    T* get() const { return ptr_; }
    T& operator*() const { return *ptr_; }
    T* operator->() const { return ptr_; }

    // 禁止拷贝，只允许移动
private:
    ObjectPool<T>* pool_;
    T* ptr_;
};

然后 ObjectPool<T>::create 返回 PooledPtr<T> 而不是裸 T*：

  • 用户拿到的是一个 RAII handle；
  • 离开作用域时自动 destroy；
  • 不再有 delete 的入口（接口里根本不给裸指针）。

这样做的理念变化：

  • 第 3 层“所有权与安全性”，开始由类型系统来表达了；
  • 错误使用（如忘记释放）更难发生，或者更早在编译期暴露。

2. 不直接暴露“地址”，而是暴露“句柄/索引”

另一个方向：不用指针，而用逻辑句柄（index + generation）：

struct Handle {
    uint32_t index;
    uint32_t generation;
};

ObjectPool 内部维护：

  • 一个 T 数组 / 向量；
  • 一个“代数”（generation）数组；
  • 一个空闲索引列表。

每次 allocate：

  • 从 free list 拿一个 index；
  • 增加这个 index 对应的 generation；
  • 返回 (index, generation) 作为 handle。

每次访问 / destroy：

  • 检查 handle 的 generation 是否匹配当前存储；
  • 如果不匹配，说明这个 handle 已经过期，拒绝访问（避免 UAF）。

这是一种常见的“安全句柄”设计，用于减少：

  • use-after-free；
  • 交叉误用不同资源的句柄。

3. 增加线程安全封装：锁或分片

要解决并发访问的问题，有两条大路：

  1. 在 ObjectPool<T> / MemoryPool 外层加粗粒度锁：
    • 简单粗暴，但能避免数据竞争；
    • 性能一般，适合少量线程、低并发。
  2. 做 per-thread pool 或 sharding：
    • 每个线程一个池，避免锁；
    • 需要上层决定对象是否只在线程内使用。

理念上，这一步是把“线程安全”也纳入到“抽象合同”中，而不是交给调用方自己约定。

九、多线程环境下的额外坑

在多线程环境里，如果直接把当前的 MemoryPool / ObjectPool<T> 共用，还会额外引入：

  • data race：多个线程同时修改 free list / 队列；
  • double allocation：两个线程同时拿到同一个空闲块；
  • free list corruption：竞争下把链表 next 指针写坏，后续所有分配/回收行为都变成未定义。

解决思路分两类：

  1. 粗粒度锁：在所有 allocate/deallocate / create/destroy 外面加 mutex：
    • 实现简单；
    • 会把 pool 变成全局热点锁，适合低并发或教学用途。
  2. 结构化并发设计：
    • 每个线程一个本地 pool（thread-local pool）；
    • 或者使用 lock-free/free-list 结构，精心设计原子操作和 ABA 防护。

这类问题已经超出了“pool 自身”的范畴，更属于“整体并发架构”的设计问题。

十、debug 模式 vs release 模式

在真实工程里，很多高性能系统会明确区分两种构建：

  • 开发 / 调试模式（Debug）：

    • 开启尽可能多的安全检查（guard bytes、分配跟踪、double free 检测等）；
    • 优先发现逻辑错误、越界、UAF，而不是追求极致性能。

  • 线上 / 发布模式（Release）：

    • 关闭大部分检查，只保留必要的断言；
    • 走最短的 fast path，最大化吞吐和延迟表现。

从理念上看，就是：

同一个 pool 设计，
在 Debug 下更偏“工具 / 监控”，
在 Release 下才是纯粹的“性能 infra”。

十一、小结：pool 给你的是“速度”，安全要靠抽象和纪律

把整篇压缩成几句话：

  • MemoryPool 关心的是“块”，ObjectPool<T> 关心的是“对象”，默认都不主动兜底内存安全；
  • 相比 malloc/new，它们往往绕过了一些 allocator 级别的保护，以更少的检查换更快的路径；
  • 如果想要安全，就要：
    • 在接口层引入 RAII / handle / 所有权模型；
    • 在实现层引入 debug 检查 / 状态标记；
    • 在体系结构层考虑线程安全和使用约束。

可以记一句话作为心智模型：

pool 主要提供的是速度；
安全性来自你在它之上设计出的抽象和使用纪律。

七、如何在现有代码基础上逐步演进？

如果你希望这个仓库里的 Pool 既能保留现在的教学直观性，又想慢慢加一点安全，可以参考一个渐进路线：

  1. 保持当前 MemoryPool 不变：
    • 继续作为最底层 raw memory 组件。
  2. 给 ObjectPool<T> 增加一个可选的“安全模式”：
    • 新增 make_handle / Handle 版本的接口，在 demo 或测试里先用起来；
    • 保留返回裸 T* 的接口用于对比（“安全 vs 快速 vs 易踩坑”）。
  3. 在 cpp-notes 里用对比代码刻意教学：
    • 同一段逻辑，分别用
      • 原始 MemoryPool + 手写析构；
      • ObjectPool<T> + 裸指针；
      • ObjectPool<T> + PooledPtr<T> / Handle；
    • 对比其可读性、错误空间和性能。

这样既能保留“看得见的坑”（教学价值），又能在后面文档里清楚说明：
如果要上生产，应该更偏向哪种设计和抽象层级。