对象池必须预分配连续内存并用索引管理空闲链表，禁止堆分配与指针存储；采用分片锁机制提升并发性能；acquire/release 不参与构造，由调用方用 placement new 或 std::construct_at 延迟初始化，并显式析构。
对象池内存必须连续且免分配
实时游戏引擎里，new 和 delete 是性能杀手，尤其在每帧高频创建/销毁小对象（比如粒子、子弹）时。固定长度对象池的核心不是“复用逻辑”，而是“绕过堆管理”——所有对象必须预分配在一块连续内存里，用数组或 std::vector<:byte></:byte> 管理原始内存，再通过 placement new 构造对象。
常见错误是用 std::vector<:unique_ptr>></:unique_ptr> 或 vector of pointers：这本质还是堆分配，只是指针数组连续，对象本身散落在各处，缓存不友好，也失去 pool 的意义。
- 用
std::vector<:byte></:byte>分配总大小 =capacity * sizeof(T)，确保对齐（alignof(T)） - 每个对象起始地址 =
base_ptr + index * sizeof(T)，强制按alignof(T)对齐（必要时手动偏移） - 构造用
new (ptr) T{...}，析构必须显式调用obj.~T()，不能依赖 vector 自动析构
free list 必须用索引而非指针
对象池的“空闲链表”如果存 T*，会在对象移动（如 resize 内存块）或跨线程传递时失效。实时引擎常需 lock-free 或轻量锁，而指针在内存重分配后直接悬空。
正确做法是只存整数索引：std::vector<size_t></size_t> 或 std::stack<size_t></size_t>，配合一个全局 base 地址计算真实指针。这样即使整个内存块被 realloc 或迁移，只要索引映射关系不变，free list 就依然有效。
立即学习“C++免费学习笔记（深入）”；
- 初始化时，free list 填满
0, 1, 2, ..., capacity-1 - 分配时 pop index，构造对象；回收时 push index，仅调用析构函数，不改内存内容
- 避免用
std::list存 free list：节点分配又引入堆操作，且 cache 不友好
多线程安全不能只靠 mutex
单个 mutex 保护整个池，在高并发分配场景下会成为热点，尤其在多核渲染/物理/音频线程同时抢资源时。但完全 lock-free 又容易出 ABA 问题，尤其涉及对象状态标记（如“是否已构造”）。
折中方案是分片（sharding）：把 pool 拆成 N 个子池（N ≈ CPU 核心数），每个线程优先访问本地子池，本地耗尽时才跨片申请。这要求对象大小固定、无跨片引用，适合粒子、事件等无状态或弱状态对象。
- 子池数量建议硬编码为 8 或 16，避免 runtime 探测 CPU 数带来的不确定性
- 每个子池独立维护自己的
std::stack<size_t></size_t>和内存块，不共享任何可写状态 - 禁止在子池间移动对象（如 transfer），否则破坏局部性与无锁前提
对象构造参数必须延迟绑定
很多实现把构造逻辑写死在 acquire() 里，比如 acquire(int x, float y)。这导致池只能服务单一构造签名，无法适配不同组件需求（比如子弹要位置+方向，粒子要颜色+生命周期）。
正确方式是让 acquire() 返回裸指针或 handle，由调用方决定如何构造——用 placement new 手动调用任意构造函数，或用 std::construct_at（C++20）。
- 池接口只提供
T* acquire()和void release(T*)，不参与构造语义 - 调用方拿到指针后，可做
std::construct_at(ptr, x, y, z)或new (ptr) T{...} - 注意：若对象含虚函数或继承关系，必须确保 vtable 初始化完整，不能只 memcpy 原始字节
最易被忽略的是对齐和析构顺序：哪怕内存连续、索引正确，如果 alignas 没对齐或析构没显式调用，UB 会在某次优化编译后突然爆发，而且很难复现。
