Item 50：理解何时值得替换 new 和 delete

从“为什么要替换”开始

void* operator new(std::size_t size);
void operator delete(void* memory) noexcept;

能写替换函数不代表应该写。系统 allocator 已处理并发、碎片、对齐、空请求和平台内存 API；自定义实现必须有可测理由。

Item 50 的原则是 Understand when it makes sense to replace new and delete（理解何时替换 new/delete 有意义）。

先预测：若 microbenchmark 显示自定义 pool 快 20%，能否直接替换 global new？还需证明真实 workload、尾延迟、内存、线程和全部 allocation forms。

动机一：检测 usage errors

典型错误包括写越界、double delete、释放陌生 pointer、use-after-free 和 new/delete family 不匹配。

[header][front guard][aligned payload][rear guard]

header 可记录 requested size、state、thread、callsite id 和校验值；delete 先验证 state 与 guards，再标记 freed。

成熟诊断工具通常优先

AddressSanitizer、Valgrind、平台 heap diagnostics 已覆盖大量越界和生命周期错误，并持续处理 ABI/线程细节。

自定义 debug allocator 适合受限平台、领域 metadata 或可控 failure injection，但不应复制一套更弱 sanitizer。先比较覆盖能力、运行开销与部署环境。

动机二：收集 allocation statistics

requested size, actual size, lifetime, thread, callsite, peak live bytes

统计可回答：小对象是否占多数、哪些 callsites 泄漏、峰值由谁造成、对象是否跨线程释放。它是后续 pool/clustering 决策的证据。

但统计代码本身不能使用被追踪的 allocator 存储无限 map/log，否则递归分配。使用预分配 ring buffer、采样或低层事件 sink。

动机三：改善 performance

通用 allocator 必须服务多种尺寸和寿命。若 workload 是大量固定尺寸、同线程分配释放的小对象，专用 free list/pool 可能减少 metadata、系统调用和锁。

std::pmr::unsynchronized_pool_resource localPool;
std::pmr::polymorphic_allocator<Node> alloc(&localPool);

优先尝试成熟 pool、arena、std::pmr resource 或平台 allocator 配置。它们把优化范围限制到 subsystem，不冒险改写整个进程。

动机四：clustering 改善局部性

一起遍历、一起销毁的对象若散落在 heap，可能增加 cache/TLB misses。arena 可让同一场景/请求的 nodes 靠近。

clustering 必须按访问关系而非仅按类型。把不同线程频繁写的对象挤在同一 cache line 还会造成 false sharing。

动机五：特殊 alignment

某些 SIMD、DMA、cache-line isolation 或硬件 buffer 要求超过普通 new 保证的 alignment。

void* memory = ::operator new(bytes, std::align_val_t{64});::
operator delete(memory, std::align_val_t{64});

现代 C++ 已有 aligned allocation 与 alignas。只有标准接口/平台 allocator 仍不能满足领域要求时，才需自定义路径；对应 aligned delete 必须匹配。

global、class-specific 与 scoped resource

优先级通常是 scoped resource，然后 class-specific，最后才是 global replacement。范围越大，越要覆盖 arrays、aligned/sized/nothrow forms、第三方库、启动/退出顺序和跨 module 边界。

替换是完整契约，不只是 malloc/free

实现必须考虑：size 为 0、失败时 new-handler/bad_alloc、alignment、thread safety、matching delete、constructor failure、sized/aligned overload 与 null delete。

不同 shared libraries 若使用不同 heaps，跨 module 分配/释放会破坏 allocator identity。

性能基准必须覆盖真实分布

只循环 allocate/free 单一尺寸会偏向 pool。有效 benchmark 应回放 allocation trace，覆盖：

1. size distribution 与 alignment。
2. object lifetime 和 live-set 峰值。
3. thread 数与 cross-thread free。
4. p50/p95/p99 latency 和 throughput。
5. RSS、internal/external fragmentation。
6. cache/TLB misses 与构建/二进制影响。

先预测自定义方案在哪些 workload 赢、在哪些输，再设置回退阈值；不是只保留最好的一张图。

一套可执行决策流程

1. 用 profiler/sanitizer/statistics 明确问题与 baseline。
2. 先尝试系统 allocator 配置、成熟 library 或 scoped pmr resource。
3. 只在最小作用域 prototype replacement。
4. 用 failure injection、alignment、thread 和 family pairing 验证契约。
5. 回放真实 traces，比较 latency、RSS、fragmentation 与 locality。
6. 保留 feature flag/回退路径，并持续监测 workload 漂移。

小结

• 替换 new/delete 的合理动机包括 usage errors、statistics、performance、clustering 和特殊 alignment
• 调试 allocator 可用 headers、guards、poisoning 和 quarantine，但必须保持 payload alignment
• 性能优化要基于真实 size/lifetime/thread trace，固定 pool 并非通用胜者
• scoped resource 或现成 allocator 通常比 global replacement 风险更小
• 自定义实现必须覆盖完整 allocation contract surface 和 allocator identity pairing
• 只有可重复 A/B 证据证明收益超过复杂度，才应发布替换