内存布局与对齐：结构体对齐、内存对齐规则、padding与packing、缓存行对齐

大家好，我是你们的老朋友。今天我们来聊聊内存布局和对齐。说实话，这个话题在C++里属于那种「平时不太注意，一踩坑就头大」的类型。我自己刚入行那会儿，就因为结构体对齐问题，把一个网络协议解析模块搞出了诡异的bug，查了整整两天才找到原因。嗯，从那以后，我对内存对齐就格外上心了。

为什么需要内存对齐？

先问大家一个问题：CPU读取内存，是一次读1个字节，还是一次读4个、8个字节？

答案是：现代CPU通常以「字」为单位读取内存。比如64位CPU，一次读8个字节。如果你的数据恰好跨了两个「字」的边界，CPU就得读两次，再拼起来。这性能损失，你想想看，是不是很亏？

所以，内存对齐的本质，就是让数据尽量落在CPU一次能读到的范围内。说白了，就是用空间换时间。

结构体对齐规则

结构体对齐比单个变量复杂一些。我总结一下，其实就三条规则：

1. 每个成员按自身大小对齐——成员变量的起始地址必须是其自身大小的整数倍。
2. 结构体整体对齐——结构体总大小必须是其最大成员大小的整数倍。
3. 编译器可能会插入padding——为了满足上述规则，编译器会在成员之间或末尾填充无用字节。

举个例子，大家看看这个结构体：

struct Example {
    char a;    // 1字节
    int b;     // 4字节
    short c;   // 2字节
};

你觉得它占多少字节？直觉上，1+4+2=7字节。但实际呢？

我们来分析一下：

• a 从偏移0开始，占1字节。
• b 需要4字节对齐，所以它不能从偏移1开始，必须从偏移4开始。于是偏移1~3被填充了3个padding字节。
• c 从偏移8开始，占2字节，到偏移9结束。
• 结构体最大成员是int（4字节），总大小必须是4的倍数。目前用了10字节（0~9），所以末尾再填充2字节，凑到12字节。

最终结果：sizeof(Example) = 12。是不是比你想的大了不少？

Padding与Packing

刚才我们看到了padding——编译器自动插入的填充字节。那能不能不要这些填充呢？可以，用 #pragma pack 或者 __attribute__((packed))。

#pragma pack(push, 1)
struct PackedExample {
    char a;
    int b;
    short c;
};
#pragma pack(pop)

// 或者GCC/Clang风格
struct __attribute__((packed)) PackedExample2 {
    char a;
    int b;
    short c;
};

这样结构体就按1字节对齐了，没有padding。上面的例子会变成7字节。

缓存行对齐

说到性能优化，缓存行对齐是个绕不开的话题。现代CPU的缓存是以「缓存行」为单位的，通常是64字节。如果两个频繁访问的变量落在同一个缓存行里，就会产生「伪共享」问题——一个核心修改变量A，会导致另一个核心的缓存行失效，即使它只访问变量B。

怎么解决？让关键变量按缓存行对齐：

struct alignas(64) CacheLineAligned {
    int data;
    // 填充到64字节
    char padding[60];
};

// 或者用C++17的std::hardware_destructive_interference_size
struct alignas(std::hardware_destructive_interference_size) ThreadData {
    int value;
};

我个人习惯在多线程高频访问的场景下，给每个线程的数据结构加上缓存行对齐。比如一个高性能日志系统，每个线程的缓冲区如果不对齐，性能可能差30%以上。

知识体系总览

下面这张图总结了本章的核心内容，大家可以对照着梳理思路：

实际项目中的选择建议

说了这么多，到底什么时候该用什么？我根据自己的经验，整理了一个表格：

场景	推荐做法	原因
普通业务逻辑	默认对齐	性能好，代码简单
网络协议/文件格式	#pragma pack(1)	精确控制内存布局，避免跨平台问题
多线程高频访问	alignas(64)	避免伪共享，提升并发性能
嵌入式/内存受限	packed + 手动对齐	节省每一字节，同时保证关键数据对齐
SIMD/向量化计算	alignas(16/32/64)	满足SIMD指令的对齐要求，否则可能崩溃