VS2017中std::map使用boost::pool_allocator清理未归还全部内存

咱们先来看你在VS2017中运行的这段代码：

#include <boost/pool/pool_alloc.hpp>
#include <map>
#include <iostream>

int main() {
    using Map = std::map<int, int, std::less<int>, boost::pool_allocator<std::pair<const int, int>>>;
    using Pool = boost::singleton_pool<boost::pool_allocator_tag, sizeof(Map)>;

    Map temp;
    for (int i = 1; i < 5; i++)
        temp[i] = i;

    std::cout << "First addresses:\n";
    for (auto& kv : temp)
        std::cout << &kv.second << "\n";

    temp.clear();
    Pool::purge_memory();

    Map temp2;
    for (int i = 1; i < 5; i++)
        temp2[i] = i;

    std::cout << "Second addresses:\n";
    for (auto& kv : temp2)
        std::cout << &kv.second << "\n";

    temp2.clear();
    Pool::purge_memory();

    return 0;
}

运行后得到的输出如下：

First addresses:
02A108F4
02A1090C
02A10924
02A1093C
Second addresses:
02A1090C
02A10924
02A1093C
02A10954

从输出能明显看到，地址02A108F4在执行Pool::purge_memory()后并没有归还给内存池，而同样的逻辑在GCC环境下内存能正常归还，用std::vector时也不会出现这个问题。

问题原因分析 #

这大概率是VS2017自带的STL实现与Boost Pool分配器的交互兼容性问题，而非Boost Pool本身的bug：

• std::map底层是红黑树结构，不同编译器的STL对红黑树节点的分配、管理逻辑存在差异。VS的STL实现可能在map::clear()时，并没有完全将所有节点内存归还给分配器（比如可能保留了一个哨兵节点或者缓存了部分节点），导致Boost Pool无法回收这部分内存。
• 而std::vector是连续内存容器，clear()会直接将所有内存归还给分配器，所以不会出现这个问题；GCC的STL对std::map节点的管理逻辑更贴合Boost Pool的预期，所以内存能正常回收。

是不是VS2017的bug？ #

严格来说，这属于STL实现细节与第三方分配器的兼容性问题。如果VS的STL没有违反C++标准中关于分配器的要求，那不能直接定义为bug，但确实是特定场景下的兼容性缺陷。你可以尝试升级VS版本（比如VS2019或更高），新版本的STL对第三方分配器的兼容性有优化，大概率能解决这个问题。

内容的提问来源于stack exchange，提问作者JHBonarius