标准分配器开销大、碎片多，不适合高频小对象；固定块内存池通过预分配4KB并用空闲链表管理64字节对象，实现无锁快速分配/回收。
为什么 std::allocator 不够用？
标准分配器每次 allocate() 都调用 ::operator new，本质是系统级内存申请，开销大、碎片多、不可控。高频小对象（如链表节点、事件结构体）反复构造/析构时，性能瓶颈明显。自定义内存池的核心目标不是“完全替代”，而是「对特定生命周期、固定大小的对象做批量预分配 + 快速复用」。
常见错误现象：malloc 调用频率高、valgrind 报大量小块内存泄漏（实为未及时归还）、STL 容器插入速度随数据量增长明显变慢。
- 适用场景：对象大小固定（如
sizeof(Node) == 32）、生命周期集中（如一帧内批量创建+统一销毁） - 不适用场景：对象大小动态变化、生命周期交错复杂、需要与其它 allocator 交互（如
std::vector<t mypoolalloc></t>但T内部又用默认 new） - 关键差异：标准 allocator 的
deallocate()是释放回系统；内存池的deallocate()通常只是把内存块挂回空闲链表，不调delete
如何写一个线程不安全但高效的固定块内存池
以单次预分配 4KB 内存块、管理 64 字节对象为例。核心是维护一个指向空闲内存起始地址的指针（m_free_list），每次分配只做指针偏移，无锁、无查找。
class FixedBlockAllocator {
static constexpr size_t BLOCK_SIZE = 4096;
static constexpr size_t OBJ_SIZE = 64;
char* m_block = nullptr;
char* m_free_list = nullptr;
public:
FixedBlockAllocator() {
m_block = new char[BLOCK_SIZE];
reset(); // 初始化空闲链表：每个块头存下一个空闲地址
}
void* allocate() {
if (!m_free_list) return nullptr;
void* p = m_free_list;
m_free_list = *static_cast<char**>(p); // 跳到下一个空闲位置
return p;
}
void deallocate(void* p) {
*static_cast<char**>(p) = m_free_list; // 头部写入当前空闲头
m_free_list = static_cast<char*>(p);
}
void reset() { // 重置整个池：所有对象可重用
m_free_list = m_block;
char* p = m_block;
for (size_t i = 0; i < BLOCK_SIZE / OBJ_SIZE - 1; ++i) {
*static_cast<char**>(p) = p + OBJ_SIZE;
p += OBJ_SIZE;
}
*static_cast<char**>(p) = nullptr; // 末尾置空
}
};注意：reset() 不释放内存，仅重置链表；OBJ_SIZE 必须 ≥ sizeof(void*)，否则无法存指针；若需支持 std::allocator 接口，需补全 construct/destroy 等成员函数，但它们不参与内存管理逻辑。
立即学习“C++免费学习笔记（深入）”；
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
怎么让 std::vector 或 std::list 用上你的内存池？
必须显式指定模板参数中的 allocator 类型，且该类需满足 Allocator 概念（C++17 起要求更严）。最简实现只需提供 value_type、allocate、deallocate、construct、destroy。
- 不要直接继承
std::allocator—— 它不是设计来被继承的，且虚函数会破坏零开销抽象 - 必须实现
rebind（C++11/14）或使用别名模板（C++17+）：template<class u> using rebind = FixedBlockAllocator<u>;</u></class> - 若容器元素类型含非平凡构造函数（如
std::string），construct()必须调用 placement-new，不能只 memcpy - 示例：
std::vector<int fixedblockallocator>> v;</int>，此时v所有元素内存都来自池，但v自身（即 capacity buffer）也由该 allocator 分配
容易被忽略的坑：对齐、异常、析构顺序
内存池本身不处理对齐——如果 OBJ_SIZE 是 64，但某个类型需要 16 字节对齐，而你从地址 0x1001 开始分配，就可能崩。务必用 alignas 或手动对齐计算起始位置。
异常安全常被跳过：allocate() 应该抛 std::bad_alloc 而不是返回 nullptr（除非明确禁用异常）；construct() 若抛异常，必须保证已分配内存能被正确回收（比如在 try/catch 中调 deallocate）。
最隐蔽的问题：析构顺序。内存池不自动调用对象析构函数；如果你用 deallocate() 归还内存前没手动调 destroy()，资源（文件句柄、内存等）就泄漏了。STL 容器在 clear() 或析构时会负责调用 destroy()，但你自己裸用 allocate/deallocate 就必须严格配对。
