内存优化需系统干预分配模式、生命周期和访问局部性，而非仅用智能指针；性能问题应通过massif/pprof/perf实测判断，避免猜测。
直接说结论：内存优化不是“加几个 std::unique_ptr 就完事”，而是从分配模式、生命周期、访问局部性三方面系统干预。多数性能卡顿和 OOM 并非因为用了 new，而是因为分配太碎、释放太晚、访问太跳。
怎么判断是不是内存问题而不是 CPU 瓶颈
别靠猜。先跑 valgrind --tool=massif 或 google-pprof --heap，看两个关键指标：
- 峰值堆内存是否随请求量线性上涨（典型泄漏）
- 分配次数/秒是否远高于实际对象创建逻辑（说明在循环里反复
new） -
massif输出中heap_tree显示大量小块（如 32B、64B）分散分布 → 外部碎片已成型
如果 perf record -e mem-loads,mem-stores 显示缓存未命中率 >15%，那大概率是内存布局或访问顺序导致，不是分配器本身的问题。
new/delete 和 malloc/free 哪个更慢
在绝大多数现代标准库实现中，new 和 malloc 底层调用的是同一套堆管理器（如 ptmalloc、jemalloc），差异几乎可以忽略。真正拖慢的不是调用开销，而是：
立即学习“C++免费学习笔记（深入）”；
-
new T会额外触发T的构造函数 —— 如果T构造开销大（比如含std::vector成员且未 reserve），这才是瓶颈 -
delete p会调用析构函数 +operator delete；而free(p)只归还内存，不碰对象状态 - 混用
new/free或malloc/delete是未定义行为，某些 libc 会直接 abort
所以选哪个，取决于你是否需要构造/析构语义，而不是“性能”。强制用 malloc 绕过构造，等于自己手写 placement new + 手动调析构，得不偿失。
什么时候该上内存池而不是智能指针
std::unique_ptr 解决的是“谁负责释放”，不是“释放得多快”。当出现以下任一情况，就该考虑内存池：
- 高频创建/销毁同类型小对象（如网络包头、AST 节点），单次
new耗时 >50ns（用std::chrono::high_resolution_clock实测） - 对象大小固定（如 96B），且生命周期明显分组（例如一个请求内批量创建，请求结束统一回收）
- 多线程下
new成为锁争用热点（gprof显示__libc_malloc占比突增）
注意：全局内存池不是银弹。二级线程本地池（TLS pool）比一级全局池更实用，避免跨核 cache line bouncing。别自己从零写，优先试 boost::pool 或 folly::PooledFixedString 这类经过压测的封装。
std::vector::reserve 和 std::vector::resize 容易搞混的点
这两个函数对内存的影响完全不同，但很多人以为都“预分配”：
-
reserve(n)：只申请原始内存，size()不变，capacity() ≥ n，后续push_back不触发 reallocation -
resize(n)：不仅分配内存，还会默认构造n个对象（调用默认构造函数），size() == n，如果原size ，新增元素被初始化；如果原 <code>size > n，末尾元素被析构
常见误用：vector<heavyobject> v; v.resize(1000);</heavyobject> → 白花 1000 次构造开销。正确做法是 v.reserve(1000);，然后用 emplace_back 按需构造。
最常被忽略的一点：内存优化的终点不是“少分配”，而是“让每次分配都值得”。比如把 100 次 16B 分配合并成 1 次 1600B 分配，再用指针偏移模拟对象布局，比任何分配器微调都管用。这需要你清楚数据的真实生命周期和访问 pattern，而不是套模板。
