问题标签 [boost-pool]

我的印象是，anobject pool是一种设计模式，用于管理一组预先分配的对象，客户端可以请求并返回其中一个对象。但是，似乎boost.pool'sobject_pool类与对象管理相比，更多的是与较低级别的内存管理有关。为什么他们用这个名字，而不是像这样的名字memory_pool？我是不是误以为 boost 的对象池真的是一个内存池方案？或者它们本质上是一样的？另外，为什么没有更高级别的对象池模式的标准实现？

背景

我之前的问题让boost.pool我详细研究了boost.pool，现在我有一个补充问题来完成我的理解。

序幕

此参考说明了有关对象池模式的以下内容：

对象池模式是一种软件创建设计模式，它使用一组随时可用的已初始化对象，而不是按需分配和销毁它们。

据我所知，boost.pool（简化的）通过内存分配和管理主要基于 a 的大小来实现对象池模式element_type，并返回一个指向已分配对象的简单指针：

一个简单的 boost 示例还表明，不需要显式free获取获取的元素：

问题

我知道在销毁池对象时分配的内存将被安全释放，但是池如何知道客户端获取的内存块何时已释放回池中并且如果其接口交回直接指针则可重用to ，但仍然不需要element_type调用 to吗？free()即如果不能确定内存是否仍在使用中，提升池如何重新使用该内存？如果它不重用这个内存，这甚至被认为与维基参考解释的模式相同吗？

我正在使用 boost pool 作为静态内存提供程序，

在上面的代码中，我们如何修复池的大小，我的意思是我们知道 boost::pool 作为静态内存分配器提供，但我无法修复这个池的大小，它一直在增长，应该有办法来限制它的大小。例如，我只想要一个包含 200 个块的池，所以我可以在这之后取 200 个块，尽管 NULL 请让我现在如何执行此操作

我试图从 Boost 库中向我的项目添加相当有限的功能，即在“pool_allocator”类的帮助下为池中的小对象分配内存，并发现我需要将项目依赖项添加到 4 个调试静态库文件和 4 发布静态库文件。即单行需要 8 个库文件依赖项，如下所示：

有没有办法在不链接到静态库的情况下使用这些类？（可能是模板参数的某种组合？）

在我正在处理的代码库中，它目前有经常这样做的代码：

基本上每次标签中的字符串发生变化时，我们都会删除旧的字母对象集并重新创建它们。这些字母对象有些轻量级，但由于这种情况经常发生，我不能简单地使用std::vector<Letter>，因为每个对象push_back()都会产生一个副本。我也想避免复制。

在这里使用提升池有帮助吗？我可以想象这样做（这是伪代码，因为我还不确定如何使用 boost pool）：

这将避免复制并避免如此频繁地进行分配。但是，我降低了代码的可维护性，因为从向量中添加/删除项目涉及太多样板。

我曾想过将 boost::ptr_vector 与自定义删除器一起使用，但不确定这是否有很大帮助。pool::malloc()它有助于清理，但每次执行 push_back 时我仍然需要调用。

使用带有 std::vector 的自定义分配器似乎也没有意义，因为它无论如何都是预先分配的并且不会缩小大小。

谁能帮我找出解决这个问题的“最佳”解决方案？

我在 Ubuntu 14.04 上安装了这样的 boost：

如果我的 CMakeLists.txt 文件中有以下内容：

Cmake 找到其他 boost 库没有问题，但是找不到pool. 我得到以下信息：

我可以看到文件在它们应该在的位置，以及其余的提升包括：

cmake 2.8.12 中是否存在错误，它期望池（仅标头库）具有 .a 或 .so 文件，还是我遗漏了什么？

我想要一个std::vector对象，使用分配的对象boost::pool。这样的事情是否正确：

这段代码有效，但我不完全确定为什么。我对分配器的概念很陌生，但是如果我理解正确，这就是告诉std::vector使用池而不是默认分配器，因此在向量中创建的任何元素都将从池中创建。

我不太确定的是：

游泳池在哪里？

我将如何直接访问池（例如释放内存）？

fast_pool_allocator包含一个池，还是我需要单独创建池并以某种方式告诉分配器使用它。

memory_pools所以我基于 boost pool制作了这个容器分配器类：

memory_pools.hpp

memory_pools.ipp

然后当我使用以下方法测试它时：

在 macOSX 10.10 上使用 clang3.5，我得到：

而当我启动时：

我有：

问题

使用 boost pool 的内存分配应该那么慢还是我的测试由于某种原因无效？

编辑

在Carmeron发表评论后，我添加了-O3and-DNDEBUG标志，现在我有了：

对于memory_pools版本，并且：

对于标准分配器版本。

问题

问题仍然存在，它变慢了正常吗？

我有以下简单的测试代码。

当我使用 Clang 或 GCC 编译此代码时，它会给出以下输出：

为什么 using 会boost::pool_allocator阻止编译器使用移动构造函数？
我错过了什么吗？

我有一个高度线程化的应用程序，它在quickfix (1.13.3)下使用 boost 的 fast_pool_allocator (1.55 版)。该应用程序在一天中分配大量对象，或多或少呈线性增长，直到我们将其关闭，到一天结束时使用大约 32G 的虚拟内存。当我们观察应用程序的虚拟内存占用量增长时，大多数分配都在 200MB 左右。但是，通常在当天晚些时候的某个时间点，boost 决定分配 6GB，即使通过应用程序的事务流没有发生重大变化。

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

问题：

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