小buffer频繁new/delete引发内存碎片，因ptmalloc在高并发不定长场景下空闲块无法合并，导致RSS上涨、malloc_trim无效；应改用零分支、无锁、cache line对齐的固定大小内存池，线程本地化+延迟回收，并依压测数据动态调优池容量。
为什么小buffer频繁new/delete会引发内存碎片
每次解析网络包都new char[1024]或std::vector<char>(1500)</char>，本质是向堆申请固定小块内存。glibc的ptmalloc在小内存分配时倾向复用fastbins或unsorted bin，但高并发、不定长（如HTTP头+body混合）场景下，释放顺序与分配顺序错位，导致bin中空闲块无法合并，实际可用内存下降，malloc开始调用sbrk或mmap，碎片就肉眼可见了。
这不是“能跑就行”的问题——压测时RSS持续上涨、malloc_trim(0)无效、valgrind --tool=massif显示heap peaks锯齿状上升，基本就是它了。
用固定大小内存池替代new/delete的实操要点
核心不是“做个池子”，而是让分配/释放路径零分支、无锁（单线程or线程本地）、且对齐到CPU cache line。别碰通用对象池（如Boost.Pool），直接管原始内存：
- 按典型包长选固定尺寸：TCP常用
1500（MTU）、HTTP/2帧用8192，避免一个包跨多个块 - 用
std::aligned_alloc(64, size)申请大页（如2MB），手动切分成等长slot，首地址存free_list指针链表 - 释放时只更新头指针：
*(char**)ptr = free_head; free_head = ptr;，不调free - 注意构造/析构：如果buffer里放
std::string等对象，得显式调placement new和obj.~T()
如何把现有解析逻辑无缝接入内存池
改代码最怕动接口。假设原来这样写：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
void on_packet(const char* data, size_t len) {
auto buf = std::make_unique<char[]>(len);
memcpy(buf.get(), data, len);
parse_http_header(buf.get(), len); // 实际解析
}改成内存池只需三处替换：
- 把
std::make_unique<char></char>换成池的acquire(len)（内部按ceil(len, block_size)取整） -
memcpy保留，但目标地址是池返回的裸指针 - 解析完调
release(ptr)而非让unique_ptr自动析构——关键点：release必须保证指针来自本池，否则直接abort
别封装成智能指针！带operator->的包装器会引入虚函数或模板膨胀，热点路径上多一次函数调用就得不偿失。
线程安全与回收时机怎么拿捏
多线程抢同一个池？别加锁——用thread_local static MemoryPool pool。每个线程独占池，解析完的buffer留在本地池里，下次直接复用。这比无锁队列快得多，也避免跨核cache bouncing。
但要注意：连接生命周期远长于单包（如WebSocket长连），不能每次release就立刻归还到free_list。得加引用计数或延迟回收——比如buffer被传给异步日志模块，就用std::shared_ptr包装池内指针，自定义deleter调pool.release。否则一释放就被其他包覆盖，debug时看到HTTP响应体里混着上个请求的cookie字段，就懂了。
真正难的是确定池大小。别凭空估算——上线后用getrusage(RUSAGE_SELF, &ru)定期采样ru.ru_maxrss，结合每秒分配次数，反推平均驻留buffer数。初始设为峰值的1.5倍，后续再收缩。
