你的C++并发写为什么越跑越慢：从缓存行争用到每核分片

64 线程并发写入 LSM-Tree MemTable 时，CPU 占用率打满，分配吞吐却从单线程的 120 万 ops 跌落至不足 15 万 ops。Linux perf 火焰图显示，热路径超过 85% 的 CPU 周期不是在执行跳表查找、键值编码或 WAL 落盘，而是在内存分配器的锁争用与跨核缓存一致性维护上。单线程下的指针碰撞（Bump-Pointer）仅需 8 条汇编指令、约 2 纳秒即可完成一次切分；一旦进入多核并发，修改全局共享的游标与剩余容量会引发总线嗅探与缓存行写失效，使轻量切分直接退化为昂贵的全局串行化等待。

针对并发写入时的锁争用与缓存行乒乓，RocksDB 采用 ConcurrentArena 实现每核分片分配。本文从单池全局锁与无锁 CAS 的硬件退化根因切入，分析 CoreLocalArray 的缓存行隔离与快速寻址，拆解双向对撞切分与批量充能逻辑，并推导线程跨核漂移与多列族场景下的内存预留放大边界。

单池并发下的共享状态修改与互斥等待

通用堆分配器（如 glibc ptmalloc）为了支持任意尺寸的内存申请与随机释放，必须在每个堆块头部维护 chunk 尺寸、使用状态标志与空闲链表指针等元数据，并在释放阶段执行空闲块合并与分箱重排。对于 LSM-Tree 的 MemTable 或编译器抽象语法树（AST）这类具备整存整销生命周期的场景，通用堆分配器的元数据开销与锁开销过高。以 RocksDB Arena 为代表的区域分配器（Region-based Allocator），通过粗粒度接管物理内存块，将分配路径简化为指针计算。

指针碰撞分配器的指令路径与无