new/delete在高频小对象场景变慢，主因是堆管理器簿记开销大、易产生外部碎片；应改用对齐优化的线程局部固定大小内存池，并避免生命周期混用与cache伪共享。
为什么 new / delete 在高频小对象场景下会变慢？
不是因为单次调用慢，而是堆管理器（如 glibc 的 malloc）为线程安全和通用性做了大量簿记：每次分配都要查空闲链表、合并相邻块、加锁、更新元数据。高频分配释放 64–256 字节的小对象时，这些开销远超实际内存使用本身，还会快速产生外部碎片——即堆中存在足够总空间，但无连续大块可用。
典型表现：valgrind --tool=massif 显示堆峰值不高，但 brk 值持续上涨；perf record -e syscalls:sys_enter_mmap,syscalls:sys_enter_munmap 发现频繁 mmap/munmap 调用。
- 避免直接在循环里对
std::vector反复push_back（尤其未预留容量） - 禁用
std::allocator默认实现，改用自定义分配器绑定到内存池 - 不要让不同生命周期的对象混入同一池——比如把网络包缓冲区和日志结构塞进同一个池，会导致“长寿命对象卡住整块内存”
如何手写一个线程局部的固定大小内存池？
核心是预分配一大块内存（如 1MB），切成等长槽位（slot），用单向空闲链表管理。关键不在“多快”，而在“不越界、不重复释放、不跨线程误用”。
以下是最简可用骨架（C++17，无锁，线程局部）：
立即学习“C++免费学习笔记（深入）”；
class FixedPool {
static constexpr size_t SLOT_SIZE = 128;
static constexpr size_t POOL_SIZE = 1024 * 1024; // 1MB
alignas(std::max_align_t) char buffer_[POOL_SIZE];
std::atomic free_list_{buffer_};
public:
FixedPool() {
// 构建空闲链表：每个 slot 指向下个 slot，末尾为 nullptr
char p = buffer_;
for (size_t i = 0; i < POOL_SIZE / SLOT_SIZE - 1; ++i) {
reinterpret_cast>(p) = p + SLOT_SIZE;
p += SLOT_SIZE;
}
reinterpret_cast(p) = nullptr;
}
void* allocate() {
char* expected = free_list_.load();
do {
if (!expected) return nullptr;
} while (!free_list_.compare_exchange_weak(expected,
*reinterpret_castzuojiankuohaophpcnchar**youjiankuohaophpcn(expected)));
return expected;
}
void deallocate(void* p) {
char* ptr = static_castzuojiankuohaophpcnchar*youjiankuohaophpcn(p);
char* expected = free_list_.load();
do {
*reinterpret_castzuojiankuohaophpcnchar**youjiankuohaophpcn(ptr) = expected;
} while (!free_list_.compare_exchange_weak(expected, ptr));
}};
注意：alignas(std::max_align_t) 确保 buffer_ 对齐；compare_exchange_weak 防止 ABA 问题；所有指针操作必须严格按 SLOT_SIZE 步进，不能依赖 sizeof(T) —— 类型无关才是池的本意。
如何避免内存池导致的 false sharing 和 cache line 断裂？
当多个 CPU 核心频繁操作同一 cache line（通常 64 字节）里的不同 slot 时，即使逻辑上互不干扰，也会因缓存一致性协议（MESI）反复使该 line 无效，性能骤降。这是比碎片更隐蔽的瓶颈。
- 强制每个 slot 占满一整个 cache line：把
SLOT_SIZE 设为 64，或向上取整到 64 的倍数
- 在 slot 开头填充 padding，确保下一个 slot 起始地址 % 64 == 0
- 避免在 pool 内部嵌套指针（如
struct { int* p; }）—— 指针目标可能落在其他 cache line，破坏局部性
- 用
perf stat -e cache-misses,cache-references 观察 miss ratio，若 > 5%，需检查对齐
std::pmr::memory_resource 能否替代手写池？
可以，但要清楚代价：std::pmr::monotonic_buffer_resource 是只增不减的，适合短生命周期上下文（如一次 HTTP 请求处理）；std::pmr::synchronized_pool_resource 内置了分代+多桶策略，但默认配置对小对象不友好，且调试困难。
实测发现：在 gcc 12.3 下，synchronized_pool_resource 分配 96 字节对象比手写固定池慢约 2.3×，原因在于其内部仍维护多个 freelist 并做哈希分桶，增加了分支预测失败概率。
建议路径：
- 先用
std::pmr::unsynchronized_pool_resource 快速验证收益（它线程不安全，但单线程下最接近手写池）
- 若压测显示延迟毛刺或吞吐不足，再切回 hand-rolled pool，并用
__builtin_assume_aligned 告知编译器对齐信息
- 永远别在池里分配 > 4KB 的对象——这已超出 L1/L2 缓存优化范围，应直走系统堆
真正难的从来不是写一个能跑的池，而是确认你的对象尺寸、生命周期、访问模式是否真的匹配池的设计假设。随便套个“高性能内存池”模板，反而容易把问题从堆碎片转移到 cache miss 或 false sharing 上。
