这里的“pool”和“buffer”可以互换使用。
假设我想在程序开始时分配一个池，以便不必一直调用new。
现在，我不想人为地限制池的大小，但如果我重新分配更大的池，所有指向旧池的指针都将失效，这肯定不太好。
我想到的一种方法是“分页”，也就是
const int NUM_PAGES = 5;
char* pool[NUM_PAGES];
您提到的内容让我想起了一个 std::deque。我不确定您是否可以直接使用 std::deque，或者您只需要使用其基本设计来实现某种类型的分配器。
当然，有一个问题，为什么要自己麻烦呢？
你说你想避免new的开销，但为什么不选择更好的new实现呢？例如，tcmalloc和jemalloc通常是多线程应用程序的非常好的竞争者。
事实上，你正在尝试创建的东西非常类似于编写定制的malloc/new实现。因此，如果你真的不想使用经过验证的实现，你将受益于那些已经这样做的人的见解。
我的个人兴趣倾向于BiBOP策略（大页面包）来对抗碎片化。其思想是针对每种分配大小有一个专用池，因此一个简单的空闲列表（与分配交错）就足够了（无需合并）。通常，只要请求的大小小于页面大小（我见过4KB被使用），任何更大的都会单独分配（在几个页面中）。废弃的页面会被回收利用。
我的主要兴趣在于使用BiBOP轻松地维护一个区间树地址范围->页头，从而通过（可能是）内部元素（如属性）的地址确定对象的完整大小，这对于垃圾回收（引用跟踪步骤）非常有用。
对于多线程分配，tcmalloc和jemalloc使用两种不同的方法：
jemalloc使用每个线程池：适用于固定数量的线程/线程池，但使得创建线程的过程更加昂贵tcmalloc使用全局多线程池，并采用无锁技术，尝试将线程平衡负载到可用的池中，以限制争用，当线程查找新的池时，如果使用的池被“锁定”（而不是等待），则会有一些争用，并且每个线程将上次使用的池缓存到线程本地变量中。因此，线程是轻量级的，但如果池的数量过低，则可能会产生一些争用。当你有一个 std::vector<T*> 时，添加元素并触发调整大小会使该容器中的引用/指针/迭代器无效，但不会影响直接寻址指向对象的引用/指针。因此，根据你实际想要使用这些引用/指针/迭代器的方式，可能需要增加一层间接性来解决问题。
在具有虚拟内存和大地址空间的系统中，你可以进行巨大的分配，而不必担心浪费任何有价值的物理内存资源，因为这些页面只有在写入时才会从物理内存资源中分配。因此，在这样的系统上，你可以为 vector 设置比实际需要更大的初始容量。
其他容器 - std::map<> 和 std::list<> - 在添加新元素时不会移动其现有元素，因此迭代器/指针/引用仍然有效。
vector（或者deque）中存储实际页面指针如何呢？我不太明白为什么需要一个链表（通常更难维护），而且页面指针的重新分配实际上不应该成为问题，因为用户代码拥有的指针指向的是页面内容，而不是指针。 - David Rodríguez - dribeas