为什么C++编译生成的二进制文件中存在大量零值块？

你看到的大块零值根本不是编译器的冗余设计，都是可执行文件格式和系统装载规则要求下的必然结果，核心来源有这几类：

• 段对齐强制填充
  不管是Linux的ELF、Windows的PE还是macOS的Mach-O格式，所有需要装载到内存的程序段（代码段、数据段、只读段等），起始偏移都必须和操作系统内存页大小对齐（主流平台默认是4KB，部分嵌入式/服务器平台是16KB/64KB）。比如你写的Hello World程序实际代码加常量可能才几百字节，为了让下一个段的起始位置落在4KB整数倍的偏移上，段与段之间的空隙会全部填0。
  这种对齐设计是为了让操作系统可以直接通过mmap类的系统调用把文件块直接映射到内存页，不需要额外做内存拷贝，同时可以给不同段单独设置内存权限（比如代码段设为只读+可执行、数据段设为可读写），大幅提升程序装载效率和运行安全性。
• 默认零值的字段与预留空间
  可执行文件里不止存代码和数据，还有大量供系统、链接器、调试器使用的元数据表：比如符号表、重定位表、异常处理表、动态链接表、调试信息段等。这些表项里大量字段的默认值就是0，同时编译器会给这些表预留一部分扩展空间，预留位置默认全部填0，方便后续链接、修改的时候不需要重新调整整个文件的结构。
  你用默认g++ hello.cpp编译出来的文件是没有去掉调试信息和符号表的，这部分元数据带来的零值占比非常高。
• 零初始化数据的特殊处理（部分场景）
  大部分未初始化的全局/静态变量会被放到BSS段，这部分数据在文件里本来不占实际存储空间，只记录长度；但如果是混合在已初始化数据段里的零散零值、结构体/对象的对齐填充字节、字符串常量的终止符等，累积起来也会形成不少连续零块。

这些零值完全不存在存储空间浪费的问题：一方面文件系统存储时，连续的零块会被稀疏文件机制识别，不会实际占用磁盘块；另一方面操作系统装载程序时，这些零页会被映射到全局共享的只读零页，只有实际写入的时候才会分配独立物理内存。如果你把文件做压缩，连续零块的压缩率接近100%，几乎不占传输带宽。

你可以自己做验证：

1. 用readelf -S a.out查看生成ELF文件的各个段偏移和长度，就能看到段之间的对齐空隙和你看到的零块位置完全对应
2. 编译时加上-s参数去掉符号和调试信息，执行g++ -s hello.cpp，你会发现文件体积直接缩水一半以上，零值占比也会明显下降
3. 如果再加链接参数-Wl,--nmagic关闭段页对齐，生成的文件体积会更小，但对应的程序装载速度会变慢，也会损失部分内存安全特性。

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