C编译器默认结构填充的原因及优势探究

一、结构体填充产生的原因 #

这事儿得从CPU的内存访问逻辑说起——现代CPU都是按固定字长批量读取内存的，比如32位CPU一次读4字节，64位CPU一次读8字节。如果某个数据的起始地址不是对应字长的整数倍，就属于「非对齐访问」：

• 轻则CPU得做两次内存读取，再把数据拼接起来（比如一个4字节的int放在地址1，CPU得先读0-3字节，再读4-7字节，然后抠出中间的1-4字节组合），效率暴跌；
• 重则直接触发硬件异常（比如部分嵌入式RISC架构，完全禁止非对齐访问，出现就直接 crash）。

C编译器为了避免这种低效甚至致命的问题，会自动在结构体成员之间（或末尾）插入「填充字节」，让每个成员的起始地址都满足对应的对齐要求。举个直观的例子：

struct Demo {
    char flag;  // 占1字节
    int count;  // 占4字节
};

如果不填充，count会从地址1开始，属于非对齐。编译器会自动在flag后面补3个填充字节，让count从地址4（4是4字节的整数倍）开始，整个结构体大小就变成8字节，而非5字节。

二、结构体填充的核心优势 #

• 极致提升内存访问效率：对齐后CPU一次就能读取完整的数据，省去了额外的拼接操作，在高频访问的场景下，性能差异会非常明显。
• 适配硬件架构要求：不少RISC架构（比如ARM的部分模式、MIPS）完全不支持非对齐访问，填充操作能保证代码在这些平台上稳定运行，不会出现莫名其妙的崩溃。
• 简化实现逻辑：编译器不用去处理复杂的非对齐访问适配，硬件也不用额外设计非对齐访问的处理电路，降低了编译器和硬件的整体复杂度。

你提到可以通过编译器扩展（比如__attribute__((packed))）禁用填充，但确实不推荐——除了性能暴跌，还可能在部分架构上直接跑不起来，只有在极端追求内存紧凑（比如嵌入式设备的帧协议、网络报文解析）的场景下才值得考虑，且必须做充分的兼容性测试。

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