这里我使用的是自定义分配器;您甚至可以说它是为了绕过其他自定义动态内存管理。

背景:我们有malloc, calloc, free的重载，以及操作符new和delete的各种变体，并且链接器很高兴地让STL为我们使用这些。这让我们可以做一些事情，如自动小对象池，泄漏检测，分配填充，自由填充，填充分配与哨兵，缓存线对齐某些分配，和延迟释放。

问题是，我们正在一个嵌入式环境中运行——没有足够的内存来在一段较长的时间内正确地进行泄漏检测。至少，不是在标准RAM中——通过自定义分配函数，在其他地方还有另一堆RAM可用。

解决方案:编写一个使用扩展堆的自定义分配器，并且只在内存泄漏跟踪体系结构的内部使用它……其他所有内容默认为执行泄漏跟踪的普通新建/删除重载。这避免了跟踪器跟踪本身(并且提供了一些额外的打包功能，我们知道跟踪器节点的大小)。

出于同样的原因，我们也使用它来保存功能成本分析数据;为每个函数调用和返回编写一个条目，以及线程切换，成本会很快增加。自定义分配器再次在较大的调试内存区域中为我们提供较小的分配。

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中，而在这些平台上可能经常出现这种情况。

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

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

我没有使用自定义STL分配器编写c++代码，但我可以想象一个用c++编写的web服务器，它使用自定义分配器自动删除响应HTTP请求所需的临时数据。自定义分配器可以在生成响应后立即释放所有临时数据。

自定义分配器(我已经使用过)的另一个可能的用例是编写一个单元测试来证明函数的行为不依赖于它的某些输入。自定义分配器可以用任何模式填充内存区域。

正如我在这里提到的，我已经看到英特尔TBB的自定义STL分配器仅通过更改单个STL分配器就显著提高了多线程应用程序的性能

std::vector<T>

to

std::vector<T,tbb::scalable_allocator<T> >

(这是一种快速方便的方式切换分配器使用TBB的漂亮的线程私有堆;见本文件第7页)

这里我使用的是自定义分配器;您甚至可以说它是为了绕过其他自定义动态内存管理。

背景:我们有malloc, calloc, free的重载，以及操作符new和delete的各种变体，并且链接器很高兴地让STL为我们使用这些。这让我们可以做一些事情，如自动小对象池，泄漏检测，分配填充，自由填充，填充分配与哨兵，缓存线对齐某些分配，和延迟释放。

问题是，我们正在一个嵌入式环境中运行——没有足够的内存来在一段较长的时间内正确地进行泄漏检测。至少，不是在标准RAM中——通过自定义分配函数，在其他地方还有另一堆RAM可用。

解决方案:编写一个使用扩展堆的自定义分配器，并且只在内存泄漏跟踪体系结构的内部使用它……其他所有内容默认为执行泄漏跟踪的普通新建/删除重载。这避免了跟踪器跟踪本身(并且提供了一些额外的打包功能，我们知道跟踪器节点的大小)。

出于同样的原因，我们也使用它来保存功能成本分析数据;为每个函数调用和返回编写一个条目，以及线程切换，成本会很快增加。自定义分配器再次在较大的调试内存区域中为我们提供较小的分配。