64位环境下std::vector执行resize抛出bad_alloc错误，疑似被限制为32位

你代码中定义的Fld结构体包含256个int型成员，单个int占4字节，因此单Fld实例占用1024字节（1KB）。当你尝试将vector resize到1亿个元素时，需要1亿 * 1KB = 100GB内存，这是触发bad_alloc的核心原因，具体可以从以下几个维度排查：

• 实际可用内存不足
  绝大多数消费级设备的物理内存都远低于100GB，即便算上虚拟内存（交换分区），也很难满足100GB的内存分配需求，内存不足时操作系统会拒绝分配请求，进而抛出bad_alloc。
• 未真正编译为64位程序
  64位编译器默认不一定生成64位程序：MSVC的默认编译目标常为x86（32位），GCC/Clang添加-m32参数时也会生成32位程序。32位程序的用户态寻址空间最大仅为4GB，远低于你需要的100GB，必然分配失败。
  验证方式：Windows下可在任务管理器的进程列表查看是否有「32位」标注；Linux下可执行file 生成的二进制文件名查看架构信息。
• vector的max_size不代表实际可分配上限
  max_size()返回的是当前寻址空间下vector理论能容纳的最大元素数，和系统实际可用内存没有关联，打印的max_size再大也不代表可以真的分配对应大小的内存。
• 连续内存分配限制
  vector需要连续的内存空间存储元素，即便系统总可用内存够100GB，要是没有足够大的连续空闲内存块，也会触发分配失败。

解决方案 #

• 先做小规模验证：将length调整为1000000（100万），此时仅需要1GB内存，若还是触发bad_alloc则可确认是程序被编译为32位的问题，修改编译目标为x64即可解决。
• 若确实需要处理1亿条以上的数据集，不要一次性全量加载到内存，可改用分块加载、内存映射文件的方式处理，避免占用过高内存。
• 调整系统虚拟内存配置：Windows可扩大分页文件大小，Linux可扩大swap分区容量，满足超大内存分配需求。

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