boost fast_pool_allocator有时会请求大量分配

Question

我有一个高度线程化的应用程序，在quickfix（1.13.3）下使用boost的fast_pool_allocator（版本1.55）。应用程序在一天中分配大量对象，线性增长直到我们关闭它，在一天结束时使用32G的虚拟内存。当我们观察应用程序的虚拟内存占用量增长时，大多数分配大约为200MB。但是，在某些时候，通常在当天晚些时候，即使通过应用程序的事务流没有实质性改变，boost也会决定进行6GB的分配。

查看分配器代码，在分配将新块设置为块后，boost首先执行的操作。该函数在simple_segregated_storage.hpp：280处为simple_segregated_storage<SizeType>::segregate。我们已经将调试器附加到进程，并观察到当巨大的分配发生时，该功能（不出所料）需要很长时间才能执行，特别是302行的for循环。它需要长达20-30秒，并且该代码是互斥保护的，因此每个其他线程都试图在分配器块中执行任何操作。这激怒了我们的客户。

问题：

1. 为什么它会在此前一整天要求约200MB的块时突然分配6GB？
2. 可以以某种方式限制分配吗？我宁愿让它更频繁地要求更小的碎片。
3. 这是错误的分配器吗？我想这对于quickfix开发人员来说是一个问题，但这似乎是他们首选的方式。使用分配器的对象大多是std::map和std::multimap。

Answer 1

正如Yakk上面提到的，事实证明，boost池允许您在模板中指定MaxSize。它有点奇怪，因为它以＆＃34; chunks＆＃34;为单位运行，这是池实现的内部概念。恕我直言的字节会更自然，但也就是这样。

fast_pool_allocator定义了所有模板参数的默认值（第一个除外）。我复制了这些默认值并更改了最后一个。对于这个应用程序，块大小是88字节，但我认为它依赖于地图中的类。

typedef std::map <int, std::vector <FieldMap*>, std::less<int>, 
                  boost::fast_pool_allocator<std::pair<const int, std::vector<FieldMap*>>,
                                             boost::default_user_allocator_new_delete,
                                             boost::details::pool::default_mutex,
                                             32,       // NextSize (default from boost)
                                             1500000   // MaxSize, in 88 byte chunks.
                                            >> Groups;

在这种情况下，1500000 * 88 = 132M，这大约是我现在要分配的大小。