64位架构下int替代long的内存节省及小数据存储相关问题

为什么使用int代替long可以减少程序的字节占用？ #

你的认知偏差核心是混淆了架构的地址位宽和单地址对应的存储容量：

• 64位架构的定义是内存地址的编号长度为64位，支持最大2^64的寻址空间，并非每个内存地址对应64位的存储空间。内存的最小寻址单位始终是字节（8位），每个地址仅对应1字节的存储空间，和架构位数无关。
• 目前主流64位系统普遍采用固定的基础数据类型长度模型：Unix类系统（Linux、macOS等）采用LP64模型，int固定为32位（4字节），long固定为64位（8字节）；Windows系统采用LLP64模型，long为32位，long long为64位。
  因此单变量场景下int本身就比同场景下的64位整数类型少占一半空间，在数组、结构体等批量存储场景下，空间差距会被进一步放大，比如长度为1024的int数组仅占用4KB空间，同长度的long数组则需要占用8KB。即使考虑内存对齐规则，连续存储的场景下int的空间优势依然明显。

长度不足64bit的数据是如何存储的？是否会统一补0？ #

该问题需要分三种场景说明：

• 变量自身的有效位存储：小于64位的变量仅占用自身类型对应的字节数，比如short占2字节、int占4字节，存储内容为对应值的二进制编码（有符号数采用补码格式），超出类型长度的地址空间不属于该变量，不会被变量的读写操作影响。
• 内存对齐的填充字节处理：编译器为了提升访存效率，通常会按照变量的自然对齐边界分配地址（比如4字节的int会对齐到4的整数倍地址），变量和下一个变量之间可能出现无意义的填充字节。填充字节的内容是未定义的，通常为内存中残留的历史数据，不会统一补0；仅当变量为全局初始化变量、或者被显式清零初始化时，变量自身的有效位会被赋值为0，填充字节依然不受影响。
• 寄存器加载的特殊处理：当小于64位的数据被加载到64位通用寄存器时，处理逻辑存在架构差异：以x86-64架构为例，写入32位寄存器低32位时会自动将寄存器高32位清0；如果是加载16位/8位有符号数到64位寄存器，会做符号扩展，高位补对应值的符号位（正数补0，负数补1），而非统一补0。

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