malloc在高频小对象分配时慢，因其需维护堆元数据、处理碎片、多线程加锁，且小对象反复申请易触发链表遍历或系统调用；内存池通过预分配大块内存并自行管理空闲链表实现O(1)无锁分配回收。
为什么直接用 malloc 在高频小对象分配时会慢？
因为 malloc 要维护堆元数据、处理碎片、加锁（多线程下），每次调用都有可观开销。小对象（比如几十字节）反复申请释放，malloc 内部可能退化为链表遍历或触发系统调用（如 sbrk 或 mmap），延迟不可控。
内存池的核心思路是：一次性向 OS 申请一大块内存（比如 4MB），自己管理这块内存的分配与回收，完全绕过 malloc 的运行时逻辑。
如何设计一个线程局部、固定大小的内存池？
最实用且高性能的做法是「每线程 + 固定块大小」，避免锁和跨核缓存行竞争。适用于已知对象大小的场景（如 std::shared_ptr 控制块、网络包头、节点结构体）。
- 用
thread_local存储每个线程独享的空闲链表（std::stack或裸指针链表） - 预分配一个大块（
new char[pool_size]），按固定block_size切割，初始化成单向空闲链表 -
alloc()直接弹出链表头，dealloc(void*)直接插回链表头 —— 都是 O(1)，无锁 - 当空闲链表为空时，才触发一次
new char[chunk_size]（比如 64KB），切块后挂入链表
class FixedSizePool {
static constexpr size_t block_size = 64;
static constexpr size_t chunk_size = 64 * 1024; // 64KB per chunk
std::stack free_list_;
std::vector> chunks_;
void grow() {
auto chunk = std::make_unique(chunk_size);
char* p = chunk.get();
for (size_t i = 0; i < chunk_size; i += block_size) {
free_list_.push(p + i);
}
chunks_.push_back(std::move(chunk));
} public:
void alloc() {
if (freelist.empty()) grow();
void ptr = freelist.top();
freelist.pop();
return ptr;
}
void dealloc(void* ptr) { free_list_.push(ptr); }};
立即学习“C++免费学习笔记（深入）”；
如何避免对象构造/析构被跳过？
裸指针池只管内存，不调用构造函数。若分配的是类对象（如 MyClass），必须显式使用 placement new 和手动析构：
- 分配后：
new (ptr) MyClass(args...)
- 销毁前：
static_cast(ptr)->~MyClass()
- 不能直接
delete ptr，也不能让智能指针默认删除器接管（它会调 delete）
- 可封装为模板类，用
std::allocator_traits 兼容 STL 容器（如 std::vector> ）
多线程共享池要不要加锁？
要，但代价高。除非有强理由（如内存极度受限、对象生命周期跨线程且无法预测），否则优先用 thread_local 池。如果真需共享：
- 用
std::atomic 实现无锁栈（CAS 循环），但要注意 ABA 问题；实践中 std::mutex 在争用不激烈时反而更稳
- 避免把整个池锁住，可分片（shard）：按地址哈希到 N 个子池，每个子池独立锁，降低冲突概率
- 注意：Linux 下
malloc 本身已做 per-thread arena，自建共享池收益常不如预期，先压测对比
真正难的不是写出来，而是确定 block_size 和 chunk_size —— 这两个值卡得不准，要么浪费内存，要么频繁 new，性能反而比 malloc 差。建议从实际分配样本中统计对象大小分布，再向上对齐到 16/32/64 字节。
