对象池的核心是预分配内存并复用以避免频繁new/delete带来的性能问题。通过std::vector管理内存块、placement new构造对象、显式析构、std::stack维护空闲偏移链表，并用mutex保障线程安全，可构建轻量高效的对象池。
对象池的核心是避免 new/delete 频繁调用
直接 new 和 delete 在高并发或高频创建销毁场景下，容易引发内存碎片、锁竞争（尤其是 malloc 的全局锁）和缓存不友好。对象池本质是预分配一批对象，复用其内存，绕过堆管理器。关键不是“池子多漂亮”，而是“怎么让 acquire() 和 release() 快且线程安全”。
用 std::vector + 自定义 allocator 最简可行
不用第三方库也能快速搭出线程安全的对象池。核心思路：预分配内存块，用 std::vector<:byte></:byte> 管理原始内存，再用 placement new 构造对象；析构时显式调用 destructor，不释放内存。
-
std::vector<:byte></:byte>一次性申请大块内存，避免多次系统调用 - 每个对象大小固定（否则无法做 slot 管理），用
sizeof(T)划分 slot - 空闲链表用
std::stack<size_t></size_t>存 offset（字节偏移），比指针更易对齐且无 dangling - 加
std::mutex保护链表操作——若性能瓶颈明显，再换std::atomic+ freelist CAS
示例片段：
class ObjectPool {
std::vector<std::byte> pool_;
std::stack<size_t> free_list_;
size_t obj_size_;
size_t capacity_;
<p>public:
ObjectPool(size_t n) : obj<em>size</em>(sizeof(T)), capacity<em>(n) {
pool</em>.resize(n <em> obj<em>size</em>);
for (size_t i = 0; i < n; ++i)
free<em>list</em>.push(i </em> obj<em>size</em>);
}</p><pre class='brush:php;toolbar:false;'>T* acquire() {
if (free_list_.empty()) return nullptr;
auto offset = free_list_.top(); free_list_.pop();
return new (&pool_[offset]) T(); // placement new
}
void release(T* ptr) {
ptr->~T(); // 显式析构
size_t offset = reinterpret_cast<std::byte*>(ptr) - pool_.data();
free_list_.push(offset);
}};
立即学习“C++免费学习笔记（深入）”；
std::shared_ptr 包裹对象会破坏池语义
如果返回 std::shared_ptr<t></t>，即使你重载了自定义 deleter，refcount 仍会堆分配控制块，且 shared_ptr 析构时可能触发 delete 行为，绕过你的 release()。这是最常踩的坑。
- 返回裸指针（
T*）或std::unique_ptr<t pooldeleter></t>更安全 - 若必须用
shared_ptr，deleter 必须捕获池实例指针，并确保池生命周期长于所有对象 - 注意：
std::unique_ptr的 deleter 类型要匹配，否则编译失败，比如PoolDeleter需是可复制/可移动的函数对象
对象构造参数传递需要变参模板支持
多数对象池只支持默认构造，但实际业务中常需带参构造（如 Connection(std::string host, int port)）。靠 acquire() 接受变参并转发给 placement new 即可。
- 把
acquire()改成模板函数：template<typename... args> T* acquire(Args&&... args)</typename...> - 内部用
new (&pool_[offset]) T(std::forward<args>(args)...)</args> - 注意：转发后不能用于
std::move已转移的右值，调用方需保证参数生命周期覆盖构造过程 - 若类型有 noexcept 构造函数，可在
acquire中加noexcept声明提升性能
对象池真正难的不是内存布局，而是生命周期边界——谁负责归还？归还时机是否遗漏？多线程下 acquire/release 是否成对？这些逻辑错误不会报编译错，但会导致 double-free 或内存泄漏。
