19、内存对齐与填充：结构体对齐，数据段对齐策略
内存对齐这个话题，说实话，很多C语言开发者写了三五年代码都不一定真正搞明白。我记得刚入行那会儿，有一次调试一个嵌入式通信协议栈，结构体明明定义得没问题，可数据就是解析不对。折腾了两天，最后发现是内存对齐在作怪——结构体里的字段被编译器偷偷塞了填充字节，导致整个布局跟我预想的完全不一样。
从那以后，我对内存对齐就格外上心。今天咱们就把这块彻底讲透。
19.1 为什么需要内存对齐？
先问个问题：CPU读取内存，是一次读1个字节，还是一次读4个、8个字节？
答案是后者。现代CPU访问内存，是以“字”为单位的。32位处理器一次读4字节，64位处理器一次读8字节。如果数据没对齐，比如一个4字节的int存放在地址0x01处，CPU就得读两次才能拿到完整数据——先读0x00~0x03，再读0x04~0x07，然后拼起来。这效率，你想想看，直接砍半。
所以，硬件设计者定了个规矩：数据的起始地址，必须是它自身大小的整数倍。这就是内存对齐的核心思想。
核心原则：任何K字节的基本对象，它的地址必须是K的倍数。
- char（1字节）：地址可以是任意值
- short（2字节）：地址必须是2的倍数
- int（4字节）：地址必须是4的倍数
- double（8字节）：地址必须是8的倍数
19.2 结构体对齐：编译器在背后做了什么
结构体对齐，说白了就是编译器在结构体成员之间插入填充字节（padding），让每个成员都满足对齐要求。同时，结构体整体的大小也要对齐到最宽成员的整数倍。
来看个例子：
struct Example1 {
char a; // 1字节
int b; // 4字节
short c; // 2字节
};你猜这个结构体占多大？直觉上，1+4+2=7字节。但实际呢？
printf("sizeof(struct Example1) = %zu\n", sizeof(struct Example1));
// 输出：12为什么会是12？我来拆解一下内存布局：
| 偏移 | 内容 | 说明 |
|---|---|---|
| 0 | char a | 占用1字节 |
| 1~3 | 填充 | 为了让int b对齐到4的倍数 |
| 4~7 | int b | 占用4字节 |
| 8~9 | short c | 占用2字节 |
| 10~11 | 填充 | 结构体整体对齐到4的倍数 |
嗯，这里要注意：结构体末尾也有填充。因为结构体数组要求每个元素都对齐，所以总大小必须是最大成员对齐值的整数倍。
个人经验：我在做网络协议解析时，经常用#pragma pack(1)来取消对齐，让结构体紧密排列。但代价是访问效率降低，而且某些平台会触发总线错误。所以，序列化用pack，运行时用默认对齐，这是我踩坑后养成的习惯。
19.3 对齐策略：如何优化结构体布局
既然编译器会填充，那我们能不能通过调整成员顺序来减少填充？当然可以。说白了，就是把大字段往前放，小字段往后放。
对比一下：
// 糟糕的布局：浪费空间
struct BadLayout {
char a; // 1字节 + 3填充
int b; // 4字节
char c; // 1字节 + 3填充
double d; // 8字节
};
// sizeof = 24
// 优化的布局：紧凑排列
struct GoodLayout {
double d; // 8字节
int b; // 4字节
char a; // 1字节
char c; // 1字节 + 2填充
};
// sizeof = 16同样的成员，只是换了个顺序，大小就从24字节降到了16字节。节省了33%的空间。我在嵌入式项目中经常做这种优化，尤其是当结构体实例数量很大时，效果非常明显。
警告：调整成员顺序虽然能节省空间，但会改变成员的偏移量。如果你的代码依赖结构体成员的绝对地址（比如用指针偏移访问），一定要小心。我曾经接手过一个遗留项目，前任为了省空间重新排列了结构体，结果没更新所有硬编码的偏移量，导致数据读写全乱了。
19.4 数据段对齐策略
结构体对齐是微观层面的，数据段对齐则是宏观层面的。编译器在生成目标文件时，会把不同数据段（.text、.data、.bss等）按照特定对齐要求放置。
常见的对齐策略包括：
- 段对齐：每个段起始地址对齐到页边界（通常是4KB或64KB）
- 符号对齐：全局变量和静态变量的地址对齐到其类型大小
- 栈对齐：函数调用时，栈帧按16字节对齐（x86-64 ABI要求）
来看一个数据段对齐的例子：
// 全局变量
char g_char; // 地址对齐到1字节
int g_int; // 地址对齐到4字节
double g_double; // 地址对齐到8字节
// 静态变量
static long g_long; // 地址对齐到8字节（64位系统）编译器在链接时，会确保这些全局变量的地址满足对齐要求。如果链接脚本没配置好，或者用了特殊的段属性，就可能导致对齐错误。
19.5 对齐相关的编译器指令
实际开发中，我们经常需要手动控制对齐。C语言提供了几种方式：
| 指令 | 作用 | 示例 |
|---|---|---|
| #pragma pack(n) | 设置最大对齐值 | #pragma pack(1) 取消对齐 |
| __attribute__((aligned(n))) | 指定变量/类型的对齐值 | int a __attribute__((aligned(64))); |
| __attribute__((packed)) | 取消结构体填充 | struct __attribute__((packed)) S { ... }; |
| alignas (C11) | C11标准对齐说明符 | alignas(16) int buf[4]; |
避坑指南：我曾经在ARM平台上用#pragma pack(1)定义了一个硬件寄存器映射结构体，结果访问某个32位寄存器时触发了异常。原因是ARM Cortex-M系列不支持非对齐访问，packed结构体里的int字段地址不是4的倍数。后来我改用memcpy来读写，才解决了问题。
19.6 对齐与性能的权衡
对齐不是免费的。严格对齐会浪费空间，但能提升访问速度。取消对齐能节省空间，但可能降低性能甚至引发错误。
我的建议是：
- 性能敏感代码：保持默认对齐，必要时手动填充到缓存行大小（64字节）
- 内存受限场景：重新排列结构体成员，减少填充
- 跨平台数据交换：使用packed结构体，配合序列化/反序列化函数
- 硬件寄存器映射：严格对齐，必要时用volatile和特定的访问宽度
19.7 知识体系总览
下面这张图总结了内存对齐与填充的核心知识点：
19.8 总结
内存对齐，说白了就是硬件和编译器之间的一种约定。理解了这个约定，你就能写出更高效、更可移植的代码。我个人习惯在定义结构体时，先按大小降序排列成员，然后检查sizeof，最后用offsetof宏验证每个成员的偏移量。这套流程帮我避免了很多低级错误。
记住一句话：对齐是编译器的事，但理解对齐是程序员的事。你越了解底层，就越能写出高质量的代码。
公众号:蓝海资料掘金营，微信deep3321