第21章内存对齐

课程目录第21章内存对齐

21. 内存对齐：alignof/alignas、结构体对齐规则、缓存行与伪共享、std::hardware_destructive_interference_size

内存对齐这个话题，说实话，很多C++开发者写了三五年代码都不太在意。但一旦你开始做高性能计算、低延迟系统，或者搞嵌入式开发，对齐问题就会像幽灵一样冒出来。我当年在做一个网络协议栈的时候，就因为结构体对齐没处理好，导致跨平台数据解析全乱套——嗯，那次排查花了我整整两天。

今天我们就把它彻底讲透。从最基础的对齐规则，到C++11引入的alignof和alignas，再到多核时代最头疼的伪共享问题，以及C++17提供的那个有点奇怪的std::hardware_destructive_interference_size。一条线串下来，你就能明白为什么内存对齐不只是“编译器帮你填几个字节”那么简单。

什么是内存对齐？为什么需要它？

简单说，内存对齐就是数据在内存中的存放地址，必须是某个值的整数倍。这个值叫“对齐系数”。比如一个int是4字节，它的地址通常得是4的倍数。

为什么会这样？因为CPU读取内存不是按字节来的，而是按“字”来的。现代CPU一次能读8字节甚至16字节。如果数据跨了两个字，CPU就得读两次，再拼起来——性能直接打折扣。我见过一个极端案例：一个结构体因为没对齐，在ARM平台上性能差了将近3倍。

核心原则：对齐是为了让CPU一次取到完整数据，避免跨边界访问。这是硬件层面的约束，不是编译器闲着没事干。

alignof 和 alignas：C++11给我们的工具

C++11引入了两个关键字，专门用来处理对齐问题。

alignof用来查询一个类型或变量的对齐要求。比如：

#include <iostream>
#include <cstddef>

struct S {
    char c;
    int i;
    double d;
};

int main() {
    std::cout << "alignof(char): " << alignof(char) << '\n';
    std::cout << "alignof(int): " << alignof(int) << '\n';
    std::cout << "alignof(double): " << alignof(double) << '\n';
    std::cout << "alignof(S): " << alignof(S) << '\n';
    return 0;
}

输出结果通常是：

alignof(char): 1
alignof(int): 4
alignof(double): 8
alignof(S): 8

注意看，结构体S的对齐要求是8，不是1也不是4。为什么？因为结构体的对齐要求，等于它所有成员中最大的那个对齐要求。这里double是8，所以整个结构体也得按8对齐。

alignas则更灵活——你可以手动指定对齐方式。比如你想让一个变量按64字节对齐（常用于缓存行对齐）：

alignas(64) int buffer[1024];

我个人习惯在写SIMD代码时大量使用alignas。比如用AVX指令集，数据得按32字节对齐，否则_mm256_loadu_si256虽然能工作，但性能不如对齐版本。

小技巧：你可以用alignas指定比默认更大的对齐，但不能指定更小的对齐。比如alignas(1) int x;是编译不过的——你不能让一个int按1字节对齐，硬件不答应。

结构体对齐规则：编译器是怎么“塞”的？

结构体对齐的规则，说白了就三条：

每个成员按自己的对齐要求存放。比如int的地址必须是4的倍数。
结构体整体对齐到最大成员的对齐值。这就是为什么结构体末尾可能有填充字节。
成员之间可能有填充字节。为了满足上一条规则，编译器会在成员之间插入一些“无用”的字节。

来看个例子：

struct A {
    char a;   // 1字节，偏移0
    // 填充3字节
    int b;    // 4字节，偏移4
    char c;   // 1字节，偏移8
    // 填充3字节（为了整体对齐到4）
}; // 总大小12字节

如果换个顺序：

struct B {
    int b;    // 4字节，偏移0
    char a;   // 1字节，偏移4
    char c;   // 1字节，偏移5
    // 填充2字节（为了整体对齐到4）
}; // 总大小8字节

看到了吗？同样的成员，只是顺序不同，大小差了4个字节。我在项目中遇到过有人把结构体成员随便乱排，结果一个包含几十个字段的结构体，愣是多出了上百字节的填充。内存倒不是大问题，但如果你要序列化传输，这些填充字节就是灾难。

注意：不要依赖结构体成员的内存布局做跨平台数据交换。不同编译器、不同架构的对齐规则可能有细微差异。如果你要搞序列化，老老实实用#pragma pack或者手动处理填充。

缓存行与伪共享：多核时代的性能杀手

现代CPU的缓存是以“缓存行”为单位的。通常一个缓存行是64字节。当CPU从内存读数据时，它一次读一整行。如果两个线程操作的是不同的变量，但这两个变量恰好在同一个缓存行里——问题就来了。

线程A修改变量X，导致整个缓存行失效。线程B的变量Y也在同一行，于是线程B的缓存也被迫失效，哪怕它根本没碰X。这就是伪共享。名字很形象：看起来是各自独立的数据，实际上在缓存层面“共享”了。

我曾经优化过一个多线程日志系统，性能死活上不去。用perf一看，缓存未命中率高得离谱。最后发现是日志缓冲区里的两个原子计数器挨在一起，两个线程疯狂抢同一个缓存行。把它们分开到不同的缓存行后，性能直接翻倍。

怎么解决？最直接的办法就是填充。让每个“热点”变量独占一个缓存行：

struct alignas(64) AlignedCounter {
    std::atomic<int> value;
    // 填充到64字节
    char padding[64 - sizeof(std::atomic<int>)];
};

但手动填充很麻烦，而且你得知道缓存行大小。不同CPU可能不一样——x86通常是64，ARM有的用32或128。

std::hardware_destructive_interference_size：C++17的救星

C++17引入了两个常量，专门解决这个问题：

std::hardware_destructive_interference_size：两个变量如果距离小于这个值，就可能发生伪共享。
std::hardware_constructive_interference_size：两个变量如果距离小于这个值，可能被加载到同一个缓存行，有利于空间局部性。

用法很简单：

#include <new>

struct alignas(std::hardware_destructive_interference_size) ThreadData {
    std::atomic<int> counter;
};

这样，每个ThreadData对象都独占一个缓存行，不会跟其他对象发生伪共享。注意，这个值在大多数x86-64平台上是64，但标准不保证——所以用这个常量才是可移植的做法。

重要：std::hardware_destructive_interference_size是编译期常量，不是运行时查询。它代表的是“这个平台上最保守的缓存行大小”。用它对性能有好处，但可能会浪费一些内存——每个对象都按64字节对齐，如果你有大量小对象，内存开销会变大。

知识体系总览

下面这张图把本章的核心逻辑串起来了：

实战建议

说了这么多，总结几条我自己的经验：

结构体成员按大小降序排列。从大到小排，填充最少。这不是硬性规定，但大多数情况下有效。
跨平台传输数据时，用#pragma pack(1)或手动序列化。别指望编译器帮你做跨平台兼容。
多线程热点数据，用alignas(std::hardware_destructive_interference_size)隔离。别心疼那几十字节，性能提升值得。
SIMD代码里，用alignas(32)或alignas(64)保证对齐。不对齐的加载指令虽然能用，但慢。

嗯，内存对齐这东西，说难不难，说简单也不简单。关键是你得知道什么时候该关心它。写业务逻辑的时候，你大可以不管；但一旦涉及性能敏感代码、底层系统、多线程并发，对齐就是绕不开的话题。希望今天的内容能帮你少踩几个坑。

📚 课程目录

21. 内存对齐：alignof/alignas、结构体对齐规则、缓存行与伪共享、std::hardware_destructive_interference_size

什么是内存对齐？为什么需要它？

alignof 和 alignas：C++11给我们的工具

结构体对齐规则：编译器是怎么“塞”的？

缓存行与伪共享：多核时代的性能杀手

std::hardware_destructive_interference_size：C++17的救星

知识体系总览

实战建议