C++中超大数组可正常运行的原因及内存分配疑问

这个现象看起来完全违背直觉，但背后是编译器优化、64位虚拟内存机制和Linux内存管理共同作用的结果，咱们一步步拆解清楚：

1. 编译器根本没给你分配整个巨型数组 #

GCC这类优化型编译器会精准分析你的代码逻辑：你只访问了数组的最后一个元素x[Nbig-1]，完全没用到数组的其他部分，也没依赖数组的连续内存特性。所以它直接跳过了“在栈上预留1e16个int空间”的操作——根本不会修改栈指针来为这个夸张的数组腾地方，而是直接计算出x[Nbig-1]对应的虚拟地址，然后对这个地址单独做读写操作。

你可以用gcc -S命令编译代码查看汇编指令，会发现根本没有sub rsp, 0x...这类栈空间分配的指令，只有计算地址、赋值、打印的操作。

2. 64位地址溢出让你得到了合法的虚拟地址 #

Nbig是1e16，乘以sizeof(int)（4字节）得到4e16字节，这个数值远大于x86-64架构用户空间的虚拟地址上限（128TB，即2^47字节）。但64位整数运算会自动溢出，计算x[0] + (Nbig-1)*4时，最终结果会被模2^64，变成一个落在用户空间范围内的合法地址。

举个简单例子：如果计算后的地址是0x10000000000000000（超过128TB），模2^64后就变成了0x0，这是一个合法的用户空间地址（哪怕通常是程序的代码段，写入时内核也会处理）。

3. Linux虚拟内存+写时复制只分配了一个物理页 #

当你对这个计算出的地址执行赋值操作时，会触发页错误：内核发现这个虚拟地址还没映射到物理内存，就会为它分配一个4KB的物理页（Linux内存分配的最小单位），然后建立映射关系。

因为你只访问了这一个地址，内核只需要分配一个物理页——这对于32GB内存的系统来说完全没压力，所以程序能正常运行并输出结果。

补充：如果强制分配整个数组会怎么样？ #

要是你用gcc -O0关闭优化，或者访问数组的多个分散元素，情况就会立刻翻车：

• 编译器会尝试修改栈指针来预留4e16字节的栈空间，这会让栈指针变成超出用户空间的非法地址，程序运行时直接触发段错误。
• 就算栈指针合法，内核也不可能拿出40PB的物理内存来满足需求，大量页错误会触发系统OOM（内存耗尽），程序会被直接杀死。

内容的提问来源于stack exchange，提问作者Rango the Great