ZLToolKit模块(三)ResourcePool(对象池)

ResourcePool

1. 核心设计理念

ResourcePool 实现了一个基于智能指针自定义删除器（Deleter）机制的高性能对象池。

其核心思想是：当用户从池中获取对象时，得到的是一个 std::shared_ptr。当这个智能指针引用计数归零（离开作用域）时，不会直接 delete 内存，而是触发自定义删除器，将对象“归还”给对象池。

测试代码和使用示例在test_resourcePool.cpp。

2. 类结构与关系分析

代码中主要涉及三个类，它们的关系如下：

2.1 ResourcePool_l<C> (内部实现类)

• 角色：这是对象池的真正实体，负责实际的内存管理、对象存储、分配和回收。
• 继承：继承自 std::enable_shared_from_this。这是为了在创建对象时，能够安全地将自身的 weak_ptr 传递给发出的智能指针，以便对象析构时能找到回家的路。
• 核心成员：
  • _objs: std::vector<C*>，存储空闲对象的栈。
  • _busy: std::atomic_flag，用于实现轻量级的自旋锁（Spinlock）。
  • _alloc: 对象分配器 lambda，默认使用 new C()。
• 关键行为：
  • Fail-fast 锁机制：在 getPtr 和 recycle 中，使用 _busy.test_and_set()。如果获取锁失败（说明有其他线程正在操作池），它不会阻塞等待，而是直接 new 一个新对象（获取时）或直接 delete 对象（回收时）。这种设计牺牲了对池大小的严格控制，换取了极高的并发性能（避免线程挂起）。

2.2 ResourcePool<C> (对外接口类/外观模式)

• 角色：这是用户直接使用的类，充当 ResourcePool_l 的 代理（Facade）或包装器。
• 关系：ResourcePool 内部持有一个 std::shared_ptr<ResourcePool_l<C>> pool。
• 存在的意义：
  • 生命周期管理：ResourcePool_l 必须以 shared_ptr 形式存在才能使用 shared_from_this()。ResourcePool 隐藏了这一细节，让用户可以像使用普通栈对象一样声明 ResourcePool。
  • 接口转发：将 obtain、setSize 等调用转发给内部的 pool。

2.3 shared_ptr_imp<C> (增强型智能指针)

• 角色：这是 ResourcePool::obtain() 返回的智能指针类型。
• 继承：继承自 std::shared_ptr<C>。
• 功能：
  • 它携带了一个 _quit 标志（atomic_bool）。
  • 提供了 quit() 方法，允许用户在持有对象期间，决定该对象销毁时是归还池中还是彻底删除。
  • 构造函数中定义了核心的回收逻辑（Deleter）。

3. 核心流程分析

A. 获取对象 (obtain / getPtr)

1. 用户调用 ResourcePool::obtain()。
2. 转发给 ResourcePool_l::obtain()。
3. 调用 ResourcePool_l::getPtr()：
   • 尝试获取自旋锁 _busy。
   • 成功：如果 _objs 有库存，弹出并返回；否则调用 _alloc() 新建。释放锁。
   • 失败（竞争激烈）：不等待，直接调用 _alloc() 新建返回。
4. 将裸指针包装成 shared_ptr_imp，并将 ResourcePool_l 的 weak_ptr 传入删除器中。

B. 回收对象 (智能指针析构)

1. shared_ptr_imp 引用计数归零，触发删除器 lambda。
2. 删除器检查 weakPool.lock() 是否能获取到 ResourcePool_l 的强引用。
   • 池已销毁：直接 delete ptr。
   • 池尚在：调用 strongPool->recycle(ptr)。
3. ResourcePool_l::recycle(ptr)：
   • 尝试获取自旋锁。
   • 成功：如果池未满，emplace_back 入队；如果池满了，delete ptr。释放锁。
   • 失败（竞争激烈）：不等待，直接 delete ptr。

4. 类图 (Class Diagram)

5. 总结

• ResourcePool 与 ResourcePool_l 的关系：是 Handle-Body (句柄-实体) 或 Proxy (代理) 的关系。ResourcePool 是面向用户的句柄，负责管理 ResourcePool_l 的生命周期；ResourcePool_l 是实际干活的实体。
• 性能特征：
  • 极高并发：使用 atomic_flag 实现无锁（Wait-free）的尝试机制，遇到竞争立即降级为直接分配/释放，杜绝了线程阻塞。
  • 安全性：使用 weak_ptr 解决循环引用和悬垂指针问题。如果池先于对象销毁，对象析构时会安全地自我删除。
• obtain vs obtain2：
  • obtain 返回 shared_ptr_imp，功能更强（支持 quit() 放弃回收），但对象体积稍大（多一个 _quit 指针）。 * obtain2 返回标准 shared_ptr，更轻量，但无法中途控制是否放弃回收

6. C++

6.1 ResourcePool_l类的成员_objs，为什么使用vector类型而不是List？

在 ResourcePool_l 中使用 std::vector<C *> 而不是 List (或 std::list)，主要是出于极致性能的考虑，特别是为了配合其自旋锁 (Spinlock) 和 Fail-fast 的设计策略。

1. 极小化临界区耗时 (最关键原因)

ResourcePool_l 使用了 std::atomic_flag (_busy) 来实现一个非阻塞的自旋锁。

• 机制：如果 test_and_set 失败（锁被占用），代码不会等待，而是直接降级为 new 或 delete 对象。
• 要求：为了提高从池中获取对象的成功率，必须极度缩短持有锁的时间。

对比两种容器的操作耗时：

• std::vector：
  • pop_back(): 仅仅是将内部的 size 计数器减 1。这是纯 CPU 指令操作，耗时在纳秒级。
  • emplace_back(): 在预留空间足够的情况下（_objs.reserve 已调用），仅仅是将指针写入数组并 size 加 1。也是纳秒级。
• std::list / List：
  • pop_back(): 需要释放链表节点的内存（调用 free 或 delete）。内存分配器本身通常包含锁，且操作耗时远高于简单的指针运算。
  • push_back(): 需要分配新的链表节点内存（调用 malloc 或 new）。

结论：使用 vector 可以将临界区缩小到仅包含几条汇编指令，极大降低了多线程竞争导致“获取锁失败”的概率。

2. 避免频繁的内存分配开销

• std::list: 每次将对象放回池中（recycle），都需要为链表节点本身分配一次内存；每次取出对象，都要释放节点内存。这违背了对象池“减少内存分配”的初衷。
• std::vector:
  • 代码中 setSize 调用了 _objs.reserve(size)。
  • 在 recycle 中有判断 if (_objs.size() >= _pool_size)。
  • 这意味着 vector 的底层数组一旦分配，在运行过程中几乎永远不需要重新分配或扩容。它仅仅是在一段连续内存上移动尾部指针。

3. 缓存局部性 (Cache Locality)

• std::vector 内部存储的是 C* 指针数组，这块内存在物理上是连续的。CPU 缓存（L1/L2 Cache）对连续内存的访问非常友好。
• std::list 的节点分散在堆内存的各个角落，遍历或访问时容易产生 Cache Miss。

4. 语义匹配 (LIFO Stack)

• 对象池的操作逻辑是：用完放回去，要用取出来。并不关心对象的顺序。
• 代码中使用的是 back() (取栈顶) 和 pop_back() (出栈) 以及 emplace_back() (入栈)。
• 这实际上是一个栈 (Stack) 结构。在 C++ 中，std::vector 是实现栈结构性能最好的容器（比 std::stack 适配器更直接）。