在图形模拟中，我看到自定义分配器用于

std::allocator不直接支持的对齐约束。 通过为短期分配(只是这个框架)和长期分配使用单独的池来最小化碎片。

一种基本情况:当编写必须跨模块(EXE/DLL)边界工作的代码时，必须保持分配和删除只发生在一个模块中。

我在Windows上的插件架构中遇到了这种情况。例如，如果你跨DLL边界传递一个std::string，任何字符串的重新分配都发生在它起源的堆中，而不是在DLL中的堆中，这可能是不同的*。

*实际上比这更复杂，如果你动态链接到CRT，这可能会工作。但是，如果每个DLL都有一个到CRT的静态链接，那么您将陷入痛苦的世界，在那里幻影分配错误不断发生。

One example of I time I have used these was working with very resource constrained embedded systems. Lets say you have 2k of ram free and your program has to use some of that memory. You need to store say 4-5 sequences somewhere that's not on the stack and additionally you need to have very precise access over where these things get stored, this is a situation where you might want to write your own allocator. The default implementations can fragment the memory, this might be unacceptable if you don't have enough memory and cannot restart your program.

One project I was working on was using AVR-GCC on some low powered chips. We had to store 8 sequences of variable length but with a known maximum. The standard library implementation of the memory management is a thin wrapper around malloc/free which keeps track of where to place items with by prepending every allocated block of memory with a pointer to just past the end of that allocated piece of memory. When allocating a new piece of memory the standard allocator has to walk over each of the pieces of memory to find the next block that is available where the requested size of memory will fit. On a desktop platform this would be very fast for this few items but you have to keep in mind that some of these microcontrollers are very slow and primitive in comparison. Additionally the memory fragmentation issue was a massive problem that meant we really had no choice but to take a different approach.

So what we did was to implement our own memory pool. Each block of memory was big enough to fit the largest sequence we would need in it. This allocated fixed sized blocks of memory ahead of time and marked which blocks of memory were currently in use. We did this by keeping one 8 bit integer where each bit represented if a certain block was used. We traded off memory usage here for attempting to make the whole process faster, which in our case was justified as we were pushing this microcontroller chip close to it's maximum processing capacity.

在嵌入式系统上下文中，我还可以看到编写自己的自定义分配器的其他情况，例如，如果序列的内存不在主ram中，而在这些平台上可能经常出现这种情况。

使用自定义分配器来使用内存池而不是堆可能会很有用。这只是众多例子中的一个。

对于大多数情况，这肯定是一个不成熟的优化。但它在某些情况下(嵌入式设备、游戏等)非常有用。

我正在使用一个MySQL存储引擎，它的代码使用c++。我们使用一个自定义分配器来使用MySQL内存系统，而不是与MySQL竞争内存。它允许我们确保我们使用的内存是用户配置MySQL使用的内存，而不是“额外的”。

I personally use Loki::Allocator / SmallObject to optimize memory usage for small objects — it show good efficiency and satisfying performance if you have to work with moderate amounts of really small objects (1 to 256 bytes). It can be up to ~30 times more efficient than standard C++ new/delete allocation if we talk about allocating moderate amounts of small objects of many different sizes. Also, there's a VC-specific solution called "QuickHeap", it brings best possible performance (allocate and deallocate operations just read and write the address of the block being allocated/returned to heap, respectively in up to 99.(9)% cases — depends on settings and initialization), but at a cost of a notable overhead — it needs two pointers per extent and one extra for each new memory block. It's a fastest possible solution for working with huge (10 000++) amounts of objects being created and deleted if you don't need a big variety of object sizes (it creates an individual pool for each object size, from 1 to 1023 bytes in current implementation, so initialization costs may belittle the overall performance boost, but one can go ahead and allocate/deallocate some dummy objects before the application enters it's performance-critical phase(s)).

标准的c++ new/delete实现的问题是，它通常只是C malloc/free分配的包装器，它适用于较大的内存块，比如1024+字节。它在性能方面有显著的开销，有时还会占用额外的内存用于映射。因此，在大多数情况下，自定义分配器的实现方式是最大化性能和/或最小化分配小对象(≤1024字节)所需的额外内存量。