malloc在高频小对象分配时慢，因其需维护堆元数据、处理碎片、多线程加锁，且小对象反复申请易触发链表遍历或系统调用；内存池通过预分配大块内存并自行管理空闲链表实现O(1)无锁分配回收。
为什么直接用 malloc 在高频小对象分配时会慢？
因为 malloc 要维护堆元数据、处理碎片、加锁（多线程下），每次调用都有可观开销。小对象（比如几十字节）反复申请释放，malloc 内部可能退化为链表遍历或触发系统调用（如 sbrk 或 mmap），延迟不可控。
内存池的核心思路是：一次性向 OS 申请一大块内存（比如 4MB），自己管理这块内存的分配与回收，完全绕过 malloc 的运行时逻辑。
如何设计一个线程局部、固定大小的内存池？
最实用且高性能的做法是「每线程 + 固定块大小」，避免锁和跨核缓存行竞争。适用于已知对象大小的场景（如 std::shared_ptr 控制块、网络包头、节点结构体）。
- 用
thread_local存储每个线程独享的空闲链表（std::stack<void></void>或裸指针链表） - 预分配一个大块（
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<void*> free_list_;
std::vector<std::unique_ptr<char[]>> chunks_;
<pre class='brush:php;toolbar:false;'>void grow() {
auto chunk = std::make_unique<char[]>(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<myclass>(ptr)->~MyClass()</myclass> - 不能直接
delete ptr，也不能让智能指针默认删除器接管（它会调delete） - 可封装为模板类，用
std::allocator_traits兼容 STL 容器（如std::vector<t poolallocator>></t>）
多线程共享池要不要加锁？
要，但代价高。除非有强理由（如内存极度受限、对象生命周期跨线程且无法预测），否则优先用 thread_local 池。如果真需共享：
- 用
std::atomic<void></void>实现无锁栈（CAS 循环），但要注意 ABA 问题；实践中std::mutex在争用不激烈时反而更稳 - 避免把整个池锁住，可分片（shard）：按地址哈希到 N 个子池，每个子池独立锁，降低冲突概率
- 注意：Linux 下
malloc本身已做 per-thread arena，自建共享池收益常不如预期，先压测对比
真正难的不是写出来，而是确定 block_size 和 chunk_size —— 这两个值卡得不准，要么浪费内存，要么频繁 new，性能反而比 malloc 差。建议从实际分配样本中统计对象大小分布，再向上对齐到 16/32/64 字节。
