std::allocator因底层直连glibc malloc，多线程下存在arena锁竞争、缓存行抖动与上下文切换开销，导致吞吐卡在10–50万alloc/s且延迟毛刺明显；高效无锁per-CPU内存池需采用ThreadLocalCache+原子free list设计，强制64字节对齐、预分配大块内存、绑定CPU核压测，并严格管控对象析构顺序。
为什么不能直接用 std::allocator 做高并发内存池
因为 std::allocator 底层通常直连 malloc/free，而 glibc 的 malloc 在多线程下会竞争全局锁（如 main_arena 或 heap_info 锁），压测时吞吐常在 10–50 万 alloc/s 就卡住，且延迟毛刺明显。真正高效的池必须绕过系统分配器、避免跨线程共享状态、消除锁争用。
如何设计无锁 per-CPU 内存池（以 64 字节对象为例）
核心是每个线程独占一个本地缓存（ThreadLocalCache），只在本地满/空时才与中心池（CentralPool）同步——中心池本身用 std::atomic + CAS 管理 free list，不加互斥锁。
-
ThreadLocalCache用固定大小数组（如 256 个指针）做栈式管理：push/pop是纯指针操作，零分支、无原子指令 - 中心池的 free list 用
std::atomic指向链表头，每次compare_exchange_weak更新，失败就重试 - 对象对齐强制为 64 字节（
alignas(64)），确保单个缓存行不被多个对象跨占，避免 false sharing - 首次分配时预申请大块内存（如 1MB），按固定 size 切成对象链表，避免频繁 mmap
示例关键片段：
struct PoolNode {
PoolNode* next;
alignas(64) char data[64];
};
std::atomic<poolnode> central_free_list{nullptr};
</poolnode>
压测时怎么暴露真实瓶颈（不是测出“假高吞吐”）
很多压测脚本只测单线程或用 std::thread 但没绑核，结果看到线程数增加吞吐反降——其实是 OS 调度抖动掩盖了池本身的性能。必须控制变量：
- 用
pthread_setaffinity_np把每个线程绑定到独立 CPU 核，禁用迁移 - 分配/释放配对：每轮循环先
alloc再free，避免缓存堆积导致误判吞吐 - 热身期跑满 1 秒再开始计时，让 TLB 和 cache 稳定
- 监控
/proc/self/status中的voluntary_ctxt_switches，超过 1000/s 就说明调度干扰严重，数据不可信
典型命令行压测工具链：taskset -c 0-7 ./bench --threads=8 --duration=5
容易被忽略的崩溃点：对象析构与内存释放顺序
如果池中对象有非平凡析构函数（比如含 std::string 成员），直接复用内存会导致析构函数不被调用，资源泄漏；但每次 free 都调用析构又破坏池的零开销目标。
- 解决方案一：池只管理 POD 类型，业务对象封装一层 handle，析构逻辑移至 handle 生命周期外
- 解决方案二：池提供
construct()/destroy()接口，由使用者显式控制，不自动调用 - 绝对禁止：在
free时用 placement new 覆盖对象前不调用析构——~T()必须显式执行，否则 C++ 对象模型未定义
这个细节在压测中不会报错，但上线后可能几天才出现诡异崩溃，调试成本极高。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
