64位环境下C++分配小于max_size的vector<bool>报bad_alloc原因

• 为vector<bool>申请50000000000个元素的存储空间时程序抛出std::bad_alloc异常，异常提示为 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc，沙箱类运行环境下程序会直接终止。
• 初步排查发现vector<bool>::max_size()返回的理论容量上限大于本次申请的元素数量，缩小申请的元素个数后程序可正常运行。
• 运行环境为64位设备，排除32位平台地址空间不足的常见诱因。

复现代码如下：

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    long size = 50000000000;
    std::vector<bool> v1;

    std::cout << "max_size: " << bool(v1.max_size() > 50000000000) <<"vs" << size << "\n";
    
    v1 = std::vector<bool>(size,false);
    cout << "vector initialised \n" << endl;
    
    cout << v1.size() << endl;
        
}

• 核心需求：实现内存高效的动态位图，用于跟踪数据结构指定地址的初始化完成状态，由于位图尺寸无法在编译期确定，无法使用固定长度的bitset。

首先需要明确一个认知：max_size()返回的是纯理论上限值，它仅根据当前平台的地址空间长度、容器size_type的取值范围计算出该容器理论上能容纳的最大元素数，完全不考虑运行时的实际可用内存、系统资源限制、内存碎片等现实约束。申请尺寸小于max_size()时分配失败，是完全符合C++标准预期的行为，max_size()从来不能作为某次内存分配一定成功的判断依据。

另外需要纠正一个计算偏差：vector<bool>是标准库的特化实现，采用位压缩存储，每个元素仅占1bit空间，50000000000个元素实际需要的连续存储空间约为5.82GiB，并非50GB。本次分配失败的常见诱因有三类：

• 运行环境的内存限制：沙箱、在线编译器、容器环境默认会给进程设置远低于6GiB的内存上限；即使是本地64位系统，如果配置了进程虚拟内存上限（比如Linux的ulimit配置、Windows的作业对象限制），或者系统开启了严格的内存过量提交规则，可用物理内存+交换分区总和不足时，都会直接拒绝内存申请。
• 整数溢出问题：代码中用long类型存储尺寸值，在Win64等采用LLP64数据模型的平台上，long是32位有符号整数，最大值仅为2^31-1，赋值50000000000会发生整数溢出，传入vector构造函数的是溢出后的非法值，也会触发分配异常。
• 连续地址空间不足：vector要求底层存储是一块连续的内存区域，即使系统总空闲内存足够，如果进程地址空间存在严重碎片化，找不到一块大小匹配的连续空闲地址区间，也会导致分配失败，该场景在单次大内存分配的测试代码中出现概率极低。

不建议使用vector<bool>实现位图，它是C++标准中公认的存在设计缺陷的特化实现，由于位访问返回代理对象而非原生bool引用，在泛型编程场景下会触发大量不符合预期的行为。针对运行期确定长度的位图需求，可选择更稳妥的方案：

• 自行实现轻量动态位图：以64位为单位分配uint64_t类型数组，自行封装位的置位、测试、清除接口，内存效率和vector<bool>完全一致，无额外开销，也能避开标准库特化版本的缺陷。
• 若跟踪的地址分布稀疏，无需预分配覆盖全地址范围的位图，可改用哈希集合存储已完成初始化的地址，内存占用会远低于全量位图。
• 若需要快速查找空位、范围置位、稀疏存储等高阶特性，可直接使用成熟的开源动态位图实现。

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