直接new/delete不适合高频小对象分配，因其引发锁竞争、内存碎片和元数据开销；内存池通过预分配大块内存+自由链表管理实现无系统调用、低开销的线程安全分配。
为什么直接 new/delete 不适合高频小对象分配
频繁调用 new 和 delete 会触发系统堆管理器介入，带来锁竞争（多线程下）、内存碎片、以及每次分配的元数据开销（通常 8–16 字节额外消耗）。尤其当对象大小固定且生命周期短（比如网络包解析中的 Packet、游戏中的 Particle），这些开销占比极高。
内存池的核心思路是：一次性向系统申请一大块连续内存（如 64KB），内部按固定块大小（如 32 字节）切分，用自由链表管理空闲块，alloc() 只是取链表头、free() 只是插回链表头——全程无系统调用、无锁（单线程）或细粒度锁（多线程）。
如何手写一个线程安全的固定块内存池
关键不是“完全自定义”，而是复用 C++ 已有机制控制行为。下面是最简可行实现的关键点：
-
std::aligned_storage_t确保内存对齐（避免new后 placement-new 构造时崩溃） - 用
std::atomic管理自由链表头指针（避免锁，但注意 ABA 问题在简单场景可忽略） - 构造/析构必须显式调用：
new (ptr) T(args...)和static_cast<t>(ptr)->~T()</t> - 不重载全局
operator new，只提供独立的PoolAllocator类，避免污染其他代码
示例核心结构：
立即学习“C++免费学习笔记（深入）”；
template<size_t BlockSize, size_t PoolSize = 4096>
class FixedBlockPool {
alignas(BlockSize) char memory_[BlockSize * PoolSize];
std::atomic<char*> free_list_{memory_};
<p>public:
void<em> alloc() {
char</em> expected = free<em>list</em>.load();
do {
if (!expected) return nullptr;
char<em> next = </em>reinterpret_cast<char**>(expected);
if (free<em>list</em>.compare_exchange_weak(expected, next)) {
return expected;
}
} while (true);
}</p><pre class='brush:php;toolbar:false;'>void free(void* ptr) {
char* expected = free_list_.load();
do {
*reinterpret_cast<char**>(ptr) = expected;
} while (!free_list_.compare_exchange_weak(expected, static_cast<char*>(ptr)));
}};
std::pmr::polymorphic_allocator 怎么用才不踩坑
这是 C++17 引入的标准化内存资源接口，比手写更安全、可组合，但容易误用：
- 别直接传
std::pmr::vector<int></int>到函数——它底层依赖当前std::pmr::memory_resource*，跨作用域可能失效 -
std::pmr::synchronized_pool_resource是线程安全的内置池，但默认块大小策略较保守；若明确知道对象尺寸，用std::pmr::monotonic_buffer_resource（单次分配、不可回收）更轻量 - 自定义
memory_resource必须重写do_allocate/do_deallocate，且do_deallocate中不能假设bytes和alignment与之前do_allocate完全一致（标准允许合并释放）
典型用法：
std::pmr::monotonic_buffer_resource pool{64_KB};
std::pmr::vector<int> v{&pool};
v.reserve(1000); // 所有内存从 pool 分配
// pool 析构时自动释放全部内存，无需逐个 delete
调试时怎么确认内存池真正在起作用
最直接方式是拦截系统调用并统计：LD_PRELOAD 替换 malloc/free（Linux）或用 Visual Studio 的 _CrtSetAllocHook（Windows），打印调用栈和 size。
更轻量的方法是在自定义池中加计数器：
- 记录
alloc()/free()次数，对比程序启动前后差值是否符合预期（比如每帧创建 100 个粒子，运行 100 帧后应 alloc 10000 次） - 在
alloc()返回前检查地址是否落在预分配的memory_区间内，否则说明泄漏到系统堆 - 用 AddressSanitizer 编译时加
-fsanitize=address，它能捕获池内越界访问，但不会误报“未初始化内存使用”——这点比 Valgrind 更准
真正难的是混合使用场景：比如池分配对象里又含 std::string，后者默认仍走系统堆。这时必须让嵌套容器也使用同一 std::pmr::polymorphic_allocator，否则内存池只管了第一层。
