默认 std::allocator 性能差且缺乏控制力：每次分配触发系统调用，无法指定内存位置、统计或缓存；自定义 allocator 需满足类型别名、allocate/deallocate、construct/destroy 和 rebind 要求。
std::allocator 的默认行为为什么不够用
默认的 std::allocator 直接调用 ::operator new 和 ::operator delete，每次分配都涉及系统调用和堆管理开销。在高频小对象场景（比如 std::vector<int></int> 频繁 push_back 导致多次扩容），这种开销会明显拖慢性能；更关键的是，它无法控制内存位置（如必须落在共享内存、GPU 显存或特定对齐区域），也无法做分配统计、泄漏检测或线程局部缓存。
实现一个最简可用的自定义 allocator（以 std::vector 为例）
要让 std::vector<int myallocator>></int> 编译通过并正常工作，你的 allocator 必须满足 C++ 标准对 Allocator 的最小契约：提供必要的类型别名、allocate/deallocate、construct/destroy，且支持 rebind（用于容器内部节点类型，如 vector 的备用空间管理器）。不需要重载 operator==（C++17 起已废弃该要求）。
-
allocate(n)返回static_cast<t>(::operator new(n * sizeof(T)))</t>—— 注意不能直接用new T[n]，因为 allocator 不负责构造 -
deallocate(p, n)必须匹配allocate的底层方式，即用::operator delete(p)，而非delete[] p -
construct(p, args...)应使用std::construct_at(p, std::forward<args>(args)...)</args>（C++20）或new (p) T(std::forward<args>(args)...)</args>（兼容旧标准） - 必须定义
rebind模板结构体，例如template<typename u> struct rebind { using other = MyAllocator<u>; };</u></typename>
template<typename T>
struct MyAllocator {
using value_type = T;
using pointer = T*;
using const_pointer = const T*;
using reference = T&;
using const_reference = const T&;
using size_type = std::size_t;
using difference_type = std::ptrdiff_t;
<pre class='brush:php;toolbar:false;'>template<typename U>
struct rebind { using other = MyAllocator<U>; };
MyAllocator() = default;
template<typename U>
MyAllocator(const MyAllocator<U>&) {}
pointer allocate(size_type n) {
if (n > std::numeric_limits<size_type>::max() / sizeof(T))
throw std::bad_alloc();
if (auto ptr = ::operator new(n * sizeof(T)))
return static_cast<pointer>(ptr);
else
throw std::bad_alloc();
}
void deallocate(pointer p, size_type) {
::operator delete(p);
}
template<typename U, typename... Args>
void construct(U* p, Args&&... args) {
std::construct_at(p, std::forward<Args>(args)...);
}
template<typename U>
void destroy(U* p) {
std::destroy_at(p);
}};
std::vector 使用自定义 allocator 的实际限制
即使你写对了 allocator，std::vector 的行为仍受其自身设计约束：它只在需要更多存储时调用 allocate，但不会主动复用已释放的小块内存；所有元素仍按顺序连续布局，无法跳过某些地址或做“稀疏分配”；而且 vector 的 capacity() 变化（如 reserve）完全由 allocator 的 allocate 决定，你无法在其中插入自定义策略（比如 fallback 到 mmap 或池子）而不修改 vector 本身。
立即学习“C++免费学习笔记（深入）”；
- 不能靠 allocator 改变 vector 的增长因子（那是 vector 实现决定的，通常为 1.5 或 2）
- 如果 allocator 抛出异常，vector 的强异常安全保证可能失效（取决于操作，如
push_back中构造失败时，已分配但未构造的内存需正确清理） - 跨 allocator 的赋值/移动（如
v1 = v2，两者用不同 allocator）在 C++11 后默认禁用，除非你显式特化std::allocator_traits<myallocator>>::is_always_equal</myallocator>为std::true_type
真正需要 allocator 的典型场景和替代方案
多数业务代码其实不需要手写 allocator。真正值得投入的场景非常具体：嵌入式设备内存受限、实时系统要求确定性延迟、游戏引擎做帧级内存池、或调试时 hook 所有分配点。否则，更推荐用更高层的方案：
- 对
std::vector单次大容量预分配：v.reserve(N)+v.resize(N)，避免多次allocate - 用
std::pmr::vector（C++17）配合std::pmr::pool_resource或std::pmr::monotonic_buffer_resource，无需改写 allocator 类型，只需传入资源对象 - 若目标是减少碎片或提升 locality，优先考虑
std::deque或自定义 chunked 容器，而非强行塞进 vector + allocator
手写 allocator 容易错在 deallocate 与 allocate 底层不一致、遗漏 rebind、或误用 new[]/delete[]——这些错误往往在释放时才暴露，且难以调试。
