直接用new/delete在高频场景下拖慢程序，因其每次调用均触发堆管理器查找空闲块、更新元数据并可能引发brk/mmap系统调用，开销可达总耗时30%以上，且无法控制对齐与布局，易致缓存错位和碎片。
为什么直接用 new 和 delete 在高频场景下会拖慢程序
因为每次调用都会触发堆管理器查找空闲块、更新元数据，还可能引发系统调用（如 brk 或 mmap）。在粒子系统、网络包解析等每秒成千上万次分配/释放的场景里，这部分开销能占到总耗时 30% 以上。更糟的是，标准分配器无法控制对齐和布局，容易造成缓存行错位或内部碎片。
free_list 链表必须用联合体（union）复用内存头
空闲链表节点不能额外申请空间存 next 指针——那等于又引入一次分配。正确做法是把每个内存块头部当作指针存储区，对象使用时才覆盖为真实数据。这要求结构体设计必须兼容两种用途：
union MemoryBlock {
char data[blockSize];
MemoryBlock* next;
};
常见错误是定义成普通结构体并单独 malloc next 数组，结果不仅多占内存，还破坏了局部性。注意 blockSize 必须 ≥ sizeof(MemoryBlock*)，否则 next 写越界。
分配时必须用 placement new，释放时必须显式调用析构函数
内存池只管地址，不管对象生命周期。跳过构造/析构会导致未定义行为，尤其涉及虚函数、成员指针或 RAII 资源时：
-
allocate()返回前要调用new(ptr) T()，不是static_cast<t>(ptr)</t> -
deallocate(T* obj)入口第一行必须是obj->~T()，否则资源泄漏 - 如果
T有非平凡析构函数但没被调用，下次用同一块内存构造新对象时，旧状态残留可能触发崩溃
线程安全不能靠全局锁硬扛
单个 free_list 加互斥锁在高并发下会成为瓶颈。实际项目中更可行的是：
- 每个线程私有池（TLS），避免竞争；空闲时再归还部分块到全局后备池
- 用 CAS 操作维护无锁栈：分配是
atomic_load+atomic_compare_exchange_weak，释放同理 - 完全放弃共享池，改用 per-connection 或 per-task 池，由业务层控制生命周期
最容易被忽略的一点：即使用了 TLS，首次访问仍需原子初始化，且 TLS 对象析构顺序不可控——池的销毁时机必须显式管理，不能依赖线程退出自动清理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
