对象池中内存分配用malloc或mmap等申请原始内存，构造必须用placement new，析构需显式调用~T()，回收仅入空闲链表；须按类型隔离、固定尺寸、避免混用；shared_ptr需自定义删除器；初始化应延迟至首次使用。
对象池该用 new 还是 malloc？
C++ 对象池里分配内存，new 和 malloc 不是二选一，而是分工明确：对象构造必须走 new（或 placement new），而底层内存申请可以交给 malloc、mmap，甚至自定义页管理器。直接用 new 分配单个对象会触发堆锁和元数据开销，反而抵消池的优势；但若只用 malloc，对象没调用构造函数，后续使用就是未定义行为。
- 用
malloc 或 aligned_alloc 预分配大块原始内存（比如 64KB）
- 用
new (ptr) T(args...) 在指定地址上构造对象
- 销毁时必须显式调用
obj->~T()，不能用 delete
- 内存回收不释放给系统，只加入空闲链表供下次复用
如何避免对象池里的内存碎片？
频繁申请/释放不同大小的对象，会让池内部出现“小块散落、大块闲置”的碎片。这不是 GC 问题，而是池设计缺陷——多数轻量级对象池只支持固定尺寸对象。
- 池必须按类型粒度隔离：
ObjectPool<foo></foo> 和 ObjectPool<bar></bar> 互不干扰
- 同一池内所有对象大小必须严格一致（编译期用
static_assert(sizeof(T) == ...) 卡住）
- 不要试图在一个池里混放
vector<int></int> 和 string —— 它们可能动态扩容，实际占用不可控
- 若真需多尺寸，用多个独立池 + 尺寸分级（如 16B/64B/256B/1KB 四级），查表分发，别做通用分配器
std::shared_ptr 能直接套在对象池对象上吗？
不能直接套，否则析构时 shared_ptr 会调用 delete，把对象还给全局堆，池就失效了。常见错误是写 std::make_shared<t>()</t>，它完全绕过池逻辑。
- 必须自定义删除器：
std::shared_ptr<t>(pool.acquire(), [pool](T* p) { pool.release(p); })</t>
- 删除器捕获的是池的引用或句柄，不能是临时对象或已销毁池实例
- 更稳妥的做法是避免智能指针裸露池细节：封装成
PooledPtr<t></t> 类，内部管理 acquire/release，对外隐藏原始指针
- 注意线程安全：如果池本身不是线程安全的，
acquire/release 必须加锁，而 shared_ptr 的引用计数原子操作不解决池竞争
对象池初始化时机不当会导致什么？
在 main() 之前（全局对象构造期）或 DLL 加载时初始化池，容易踩到静态初始化顺序问题（SIOF）：池依赖的内存管理器还没准备好，或者池被多个 TU 初始化两次。
- 池对象不要声明为全局变量，改用局部静态或
std::call_once 延迟初始化
- 如果必须全局可用，用函数返回引用：
ObjectPool<foo>& get_foo_pool() { static ObjectPool<foo> pool; return pool; }</foo></foo>
- 禁止在类静态成员初始化器里调用
get_foo_pool().acquire() —— 此时池可能尚未构造
- 单元测试中反复创建/销毁池实例时，确保析构顺序正确，尤其涉及
mmap 内存时，提前释放可能导致野指针
malloc 或 aligned_alloc 预分配大块原始内存（比如 64KB）new (ptr) T(args...) 在指定地址上构造对象obj->~T()，不能用 delete
- 池必须按类型粒度隔离：
ObjectPool<foo></foo>和ObjectPool<bar></bar>互不干扰 - 同一池内所有对象大小必须严格一致（编译期用
static_assert(sizeof(T) == ...)卡住） - 不要试图在一个池里混放
vector<int></int>和string—— 它们可能动态扩容，实际占用不可控 - 若真需多尺寸，用多个独立池 + 尺寸分级（如 16B/64B/256B/1KB 四级），查表分发，别做通用分配器
std::shared_ptr 能直接套在对象池对象上吗？
不能直接套，否则析构时 shared_ptr 会调用 delete，把对象还给全局堆，池就失效了。常见错误是写 std::make_shared<t>()</t>，它完全绕过池逻辑。
- 必须自定义删除器：
std::shared_ptr<t>(pool.acquire(), [pool](T* p) { pool.release(p); })</t>
- 删除器捕获的是池的引用或句柄，不能是临时对象或已销毁池实例
- 更稳妥的做法是避免智能指针裸露池细节：封装成
PooledPtr<t></t> 类，内部管理 acquire/release，对外隐藏原始指针
- 注意线程安全：如果池本身不是线程安全的，
acquire/release 必须加锁，而 shared_ptr 的引用计数原子操作不解决池竞争
对象池初始化时机不当会导致什么？
在 main() 之前（全局对象构造期）或 DLL 加载时初始化池，容易踩到静态初始化顺序问题（SIOF）：池依赖的内存管理器还没准备好，或者池被多个 TU 初始化两次。
- 池对象不要声明为全局变量，改用局部静态或
std::call_once 延迟初始化
- 如果必须全局可用，用函数返回引用：
ObjectPool<foo>& get_foo_pool() { static ObjectPool<foo> pool; return pool; }</foo></foo>
- 禁止在类静态成员初始化器里调用
get_foo_pool().acquire() —— 此时池可能尚未构造
- 单元测试中反复创建/销毁池实例时，确保析构顺序正确，尤其涉及
mmap 内存时，提前释放可能导致野指针
std::shared_ptr<t>(pool.acquire(), [pool](T* p) { pool.release(p); })</t>
PooledPtr<t></t> 类，内部管理 acquire/release，对外隐藏原始指针acquire/release 必须加锁，而 shared_ptr 的引用计数原子操作不解决池竞争main() 之前（全局对象构造期）或 DLL 加载时初始化池，容易踩到静态初始化顺序问题（SIOF）：池依赖的内存管理器还没准备好，或者池被多个 TU 初始化两次。
- 池对象不要声明为全局变量，改用局部静态或
std::call_once延迟初始化 - 如果必须全局可用，用函数返回引用：
ObjectPool<foo>& get_foo_pool() { static ObjectPool<foo> pool; return pool; }</foo></foo> - 禁止在类静态成员初始化器里调用
get_foo_pool().acquire()—— 此时池可能尚未构造 - 单元测试中反复创建/销毁池实例时，确保析构顺序正确，尤其涉及
mmap内存时，提前释放可能导致野指针
对象池真正难的不是分配逻辑，而是生命周期边界的对齐：谁负责构造、谁负责析构、谁决定内存归还时机。这三个点只要错一个，性能提升就变成内存错误。
