19. 结构体与性能优化：缓存行对齐、减少内存碎片、访问效率优化
说到结构体，很多人觉得不就是把几个变量打包嘛。嗯，这话没错。但你要知道，打包的方式不同，程序的性能可能差好几倍。我见过一个项目，就因为结构体布局没注意，缓存命中率掉了30%。今天咱们就聊聊，怎么让结构体跑得更快。
19.1 缓存行对齐：别让CPU空等
现代CPU不是一次只读一个字节的。它一次读64字节，这64字节就叫一个缓存行。如果你的结构体横跨了两个缓存行，CPU就得读两次。说白了，这就是浪费。
核心原则：结构体起始地址和大小，最好是64字节的倍数。这样能保证它完整落在一个缓存行里。
我在项目中遇到过一个问题：一个网络包处理的结构体，大小是68字节。每次访问都要跨两个缓存行，性能直接掉了15%。后来我加了个padding，补到128字节，问题就解决了。
// 不好的做法：跨缓存行
struct packet {
uint32_t len; // 4字节
uint8_t data[60]; // 60字节
uint16_t crc; // 2字节
// 总共66字节，跨两个缓存行
};
// 好的做法：对齐到缓存行
struct packet_aligned {
uint32_t len;
uint8_t data[60];
uint16_t crc;
uint8_t __pad[2]; // 补到64字节
} __attribute__((aligned(64)));小技巧：GCC和Clang都支持__attribute__((aligned(64)))。如果你用C11，也可以用alignas(64)。我个人习惯用GCC的扩展，因为更直观。
19.2 减少内存碎片：结构体布局的艺术
内存碎片是个隐形杀手。你申请了100个结构体，每个都因为对齐而多占几个字节，积少成多，内存利用率就下来了。更麻烦的是，碎片多了，malloc可能失败。
为什么会这样？因为结构体里的成员有对齐要求。比如一个uint64_t必须从8的倍数地址开始。如果你把小的成员放在大的后面，中间就会产生空洞。
// 糟糕的布局：产生大量空洞
struct bad_layout {
char a; // 1字节，偏移0
uint64_t b; // 8字节，偏移8（中间7字节空洞）
char c; // 1字节，偏移16
uint32_t d; // 4字节，偏移20（中间3字节空洞）
// 总大小：24字节，实际只用了14字节
};
// 优化的布局：按大小降序排列
struct good_layout {
uint64_t b; // 8字节，偏移0
uint32_t d; // 4字节，偏移8
char a; // 1字节，偏移12
char c; // 1字节，偏移13
// 总大小：16字节，实际用了14字节
};注意：我曾经犯过一个错，为了减少碎片把成员顺序打乱了，结果导致代码可读性变差。后来我学乖了：先按逻辑分组，再在组内按大小排序。这样既清晰又高效。
19.3 访问效率优化：热数据放前面
你想想看，CPU访问结构体成员时，如果频繁访问的成员分散在不同的缓存行里，那缓存就一直在换入换出。这就像你翻书，每次都要翻到不同的章节，效率能高吗？
我的做法是：把最常访问的成员放在结构体开头。这样它们大概率在同一个缓存行里，一次加载就能用很久。
// 一个游戏引擎中的例子
struct player {
// 热数据：每帧都访问
float x, y, z; // 位置
float health; // 血量
uint32_t state; // 状态标志
// 冷数据：偶尔访问
char name[32]; // 玩家名
uint64_t experience; // 经验值
uint32_t level; // 等级
};经验之谈：如果你不确定哪些是热数据，可以用性能分析工具（比如perf）看看缓存缺失率。我一般要求热数据的总大小不超过64字节，这样一次缓存行加载就能覆盖所有热数据。
19.4 实战：一个网络协议栈的优化案例
我记得有一次优化一个嵌入式网络协议栈。原来的结构体是这样的：
struct net_packet {
uint8_t header[14]; // 以太网头
uint8_t payload[1500];// 数据
uint32_t checksum; // 校验和
uint8_t flags; // 标志位
uint16_t length; // 实际长度
};这个结构体有几个问题：
- 校验和、标志位、长度这些控制信息分散在payload后面，每次访问都要跳过1500字节
- 结构体总大小超过缓存行，频繁访问时缓存缺失严重
- 成员顺序不合理，产生不必要的对齐空洞
优化后的版本：
struct net_packet_fast {
// 控制信息放前面
uint32_t checksum; // 偏移0
uint16_t length; // 偏移4
uint8_t flags; // 偏移6
uint8_t __pad[1]; // 对齐到8字节
// 数据部分
uint8_t header[14]; // 偏移8
uint8_t payload[1500];// 偏移22
} __attribute__((aligned(64)));优化后，控制信息都在前8字节里，一次缓存行加载就能拿到所有控制数据。处理每个包的时间从原来的120纳秒降到了85纳秒。嗯，这就是对齐和布局的力量。
19.5 知识体系图
19.6 避坑指南
最后，分享几个我踩过的坑：
- 别过度对齐：我曾经把所有结构体都对齐到64字节，结果内存占用翻了一倍。后来发现，只有频繁访问的热结构体才需要这么做。
- 小心位域：位域的对齐行为是编译器相关的。我在ARM和x86上就遇到过不同的布局。如果你要跨平台，慎用位域。
- 别忘了packed：有些场景（比如网络协议、文件格式）需要精确控制布局，可以用
__attribute__((packed))。但注意，packed结构体的访问速度会慢一些，因为CPU要做非对齐访问。
我的习惯：写结构体之前，先画个内存布局图。把每个成员的偏移量算清楚，看看有没有空洞。这个习惯帮我避免了很多性能问题。
好了，关于结构体的性能优化就聊到这里。记住一句话：结构体的布局，决定了缓存的效率；缓存的效率，决定了程序的性能。下次写结构体时，多想想你的数据是怎么被访问的。