线程本地内存池能消除分配锁竞争，因每个线程独占预分配内存块并维护本地空闲链表，分配/释放全程无锁；仅池耗尽时才低频触发全局锁。
直接用线程本地内存池（thread-local pool）替代全局锁保护的分配器，能几乎消除分配路径上的锁竞争。
为什么全局 new/delete 在高并发下必然卡锁
标准 operator new 底层依赖堆管理器（如 ptmalloc、jemalloc），这些实现内部对元数据操作加了全局或分段锁。即使你没显式加锁，new 和 delete 调用本身就会在高并发时排队等待——尤其当对象大小不固定、触发 mmap 或 heap 扩展时，锁争用更剧烈。
- 现象：perf record 显示大量时间花在
__libc_malloc或je_malloc的锁路径上 - 本质不是你代码写错，而是堆管理器设计使然：它必须保证跨线程的内存布局一致性
- 解决方向不是“优化锁”，而是绕过锁——让线程尽量不碰共享堆元数据
用 thread_local + 固定大小内存池切断锁链
每个线程独占一块预分配的内存块，并维护自己的空闲链表。分配和释放全程无锁，只在本地指针/索引上做原子读写（甚至可完全免原子）。
- 分配时：从
thread_local的free_list头取节点，O(1)，无锁 - 释放时：插回同一线程的
free_list头，O(1)，无锁 - 仅当本地池耗尽或溢出时，才触发一次全局池的批量申请/归还（此时才需锁，但频次极低）
- 示例关键结构：
thread_local static std::unique_ptr<fixedsizememorypool> local_pool; void* allocate() { if (!local_pool) local_pool = std::make_unique<fixedsizememorypool>(1024); return local_pool->allocate(); }</fixedsizememorypool></fixedsizememorypool>
别踩这几个坑：对齐、回收延迟、跨线程释放
看似简单，实际部署时这三个点最容易导致性能不升反降或崩溃。
-
alignas(64)必须加在内存块起始处，否则多个对象挤进同一缓存行，引发伪共享——哪怕没锁，CPU 核心间反复同步缓存行也会拖慢 3~5 倍 - 禁止把一个线程分配的对象交给另一个线程
delete：这会破坏本地池完整性，轻则内存泄漏，重则空闲链表指针错乱 - 如果对象生命周期跨越线程（比如生产者分配、消费者释放），必须走“延迟回收”机制：释放时不立即归还，而是先入线程本地回收队列，由后台线程定期合并到全局池
- 验证是否生效：用
perf stat -e 'syscalls:sys_enter_brk,syscalls:sys_enter_mmap'看系统调用次数是否骤降
真正难的不是写出来，而是确认每个对象的分配/释放路径都严格落在同一线程上下文中——编译期无法检查，得靠运行时日志或 ASan + ThreadSanitizer 配合验证。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
