如何防止在 boost::fast_pool_allocator 管理的对象上调用析构函数？

Question

我想利用boost::fast_pool_allocator 的以下广告功能（请参阅the Boost documentation for Boost Pool）：

例如，您可能遇到想要分配一个 一堆小物体在一个点，然后到达你的一个点 不再需要它们的程序。使用池接口， 你可以选择运行它们的析构函数或者只是把它们放到 遗忘...

（请参阅 here 获取此报价。）

关键短语是让他们被遗忘。我不想要在这些对象上调用析构函数。

（原因是我有数百万个微小的对象，它们在堆上形成了一个极其复杂的所有权网络，当单个父级对象离开时，我的程序需要大约 20 分钟来调用所有的析构函数堆栈。我不需要调用这些析构函数，因为没有预期的副作用，并且所有内存都包含在 boost::pool 中。）

不幸的是，尽管有上述文档的承诺，以及boost::pool 概念的承诺，我还是找不到阻止托管对象的析构函数被调用的方法。

问题很容易在一个小示例程序中分离出来：

class Obj
{
public:
    ~Obj()
    {
        // Placing a breakpoint here indicates that this is *always* reached
        // (except for the crash scenario discussed below)
        int m = 0;
    }
};

typedef std::map<int, Obj, std::less<int>,
                 boost::fast_pool_allocator<std::pair<int const, Obj>>>
        fast_int_to_int_map;

class Foo
{
public:
    ~Foo()
    {
        // When the following line is uncommented, the program CRASHES
        // when the destructor is exited - because the Obj destructors
        // are called on the invalid Obj ghost instances

        //boost::singleton_pool<boost::fast_pool_allocator_tag,
        //                  sizeof(std::pair<int const, Obj>)>::purge_memory();
    }

    fast_int_to_int_map mmap;
};

void mfoo()
{
    // When this function exits, the Foo instance goes off the stack
    // and its destructor is called, in turn calling the destructors
    // of the Obj instances - this is NOT desired!

    Foo foo;
    foo.mmap[0] = Obj();
    foo.mmap[1] = Obj();
}

int main()
{
    mfoo();

    // The following line deallocates the memory of the pool just fine -
    // but does nothing to prevent the destructors of the Obj instances
    // from being called

    boost::singleton_pool<boost::fast_pool_allocator_tag,
                          sizeof(std::pair<int const, Obj>)>::purge_memory();
}

如代码 cmets 中所述，始终调用由 boost::pool 管理的 Obj 实例的析构函数。

我能做些什么来让 Boost Pool 文档中的有希望的引述 drop them off into oblivion 成真？

Answer 1

默认情况下，池使用default_user_allocator_new_delete 分配器。这将通过首先调用析构函数然后回收底层内存来破坏底层对象。 default_user_allocator_malloc_free 将导致 malloc 的内存在不触发析构函数的情况下被回收 - 因此 drop[ing] them off into oblivion。

也就是说，如果您的树真的那么复杂，那么使用 free 而不是触发析构函数似乎是一种非常好的方法，可以开始从您自己的下方切出分支并可能开始泄漏您无法再访问的内存。

Answer 2

您将自定义分配器传递给您的 std::map 类。因此，此分配器将用于std::map 内的所有内容：用于所有Obj 数据以及std::map 二叉树的节点。结果，如果你在Foo的析构函数中调用purge_memory()，那么这部分内存就会失效，并在std::map析构函数中崩溃。

您认为自定义分配器负责对象解除分配的假设是不正确的：释放所有对象是std::map 的任务。因此，无论您传递自定义分配器还是使用默认分配器，都会调用~Obj()。

对于您的问题，我没有看到任何优雅的解决方案。但是这种方法应该可行：

• 使用placement new 从池的内存中创建Foo 对象，
• 照常使用这个Foo对象，
• 调用purge_memory() 释放池中的所有内存。不会调用 ~Obj 或 ~std::map 的析构函数。

Answer 3

此问题的答案包含在@qehgt 答案下方的 cmets 中，详细信息请参见 this new question。

即：

在对象实例化和删除的两个相关方面之间有一个明确而正式的区别：

• (1) 内存的分配和释放

• (2) 构造函数和析构函数的调用

自定义分配器的用途仅是 (1)。

容器对象句柄 (2)，它们调用自定义分配器中的函数来确定构造对象的内存位置，并告诉自定义分配器可以为给定对象释放分配的内存。 但是对构造函数/析构函数本身的调用是由容器进行的，而不是由自定义分配器进行的。

因此，实现本题目的的方法如下：通过new声明容器对象，并在其上NEVER CALL delete（但使用自定义分配器保证你后面创建的对象在容器存储在内存池中，然后通过调用purge_memory()自己手动释放内存池）：

class Obj { // has operator<() for use with std::set };

typedef std::set<Obj, std::less<Obj>, boost::fast_pool_allocator<Obj>> fast_set_obj;

// Deliberately do not use a managed pointer -
// I will *NOT* delete this object, but instead
// I will manage the memory using the memory pool!!!
fast_set_obj * mset = new fast_set_obj;

// ... add some Obj's to 'mset'
mset->insert(Obj());
mset->insert(Obj());

// Do something desireable with the set ...
...

// All done.
// It's time to release the memory, but do NOT call any Obj destructors.
// The following line of code works exactly as intended.

boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(Obj const)>::purge_memory();

（上面的代码取自上面的链接问题。）

但是，我仍然有一个问题，与当前问题背后的意图没有直接关系：如果使用 map 而不是 set，则上面的代码不起作用。详情请见linked question。