Hey there, let’s break down memory alignment nice and clear—it can feel like a confusing low-level detail at first, but once you connect it to how hardware actually works, it all clicks. Let’s start with what it does, then why it’s non-negotiable.

内存对齐的核心作用 #

• 大幅提升CPU访问效率：现代CPU不会逐个字节读取内存，而是按自身原生位宽（32位CPU是4字节、64位是8字节）读取整块数据（称为“字”）。如果数据没有对齐到这些块的边界，CPU就得读取两个独立块，切割出需要的部分再拼接起来，额外操作会显著拖慢速度。比如，一个4字节的int存在地址1（而非0、4、8这类对齐地址），32位CPU就得先读0-3地址块，再读4-7地址块，最后提取1-4字节的有效数据——比直接读取一个对齐块慢得多。
• 避免硬件错误：一些老旧的RISC架构、嵌入式系统或外设硬件完全不支持非对齐内存访问，遇到这种情况会直接抛出硬件异常、返回垃圾数据甚至崩溃程序。这不是“软件选择”，而是硬件设计的硬性限制。
• 优化缓存利用率：CPU缓存被划分为固定大小的“缓存行”（通常64字节）。对齐的数据能完整适配缓存行，避免单个数据跨两个缓存行的情况。如果数据跨行了，CPU必须加载两个缓存行才能访问一个值，既浪费缓存空间又拖慢速度。

为什么必须进行内存对齐？ #

本质上源于三个不可妥协的因素：

1. CPU硬件限制：连接CPU与内存的总线是按固定宽度传输数据的，对齐地址能让总线一次性传输CPU需要的全部数据。非对齐访问会强制额外的总线周期和CPU处理来重构数据——这是硬件层面的基础限制，不是靠代码技巧就能绕开的。
2. ABI与编译器规则：每个操作系统都定义了应用二进制接口（ABI），指定了数据类型的对齐要求（比如int必须对齐到4字节、double对齐到8字节）。如果无视这些规则，代码在与系统库、其他编译模块交互时会崩溃。比如你定义的结构体不遵循对齐规则，其内存布局会和系统头文件中的同结构体不一致，传递数据时会导致数据损坏。
3. 一致性与可移植性：对齐能保证代码在不同架构和编译器下表现一致。一个在x86机器上正确对齐的结构体，在ARM机器上也能正常工作（只要遵循目标平台的ABI），而非对齐代码可能在非x86系统上崩溃或产生错误结果。

简单代码示例 #

看看编译器如何处理结构体的对齐：

// 假设编译器不自动对齐（实际大多会自动处理）
struct UnalignedStruct {
    char c;  // 1字节
    int i;   // 4字节
    // 总大小5字节，但i从地址1开始
};

// 编译器自动添加对齐填充
struct AlignedStruct {
    char c;          // 1字节
    char padding[3]; // 编译器自动添加3字节填充
    int i;           // 4字节，从地址4（对齐地址）开始
    // 总大小8字节
};

在对齐版本中，int刚好位于可被4整除的地址上，CPU能在一个周期内完成读取。

Hope that clears things up—memory alignment is all about playing nice with how hardware actually works to keep your code fast, reliable, and portable. If you’ve got specific edge cases or code examples you’re stuck on, feel free to follow up!

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