1.1 结构体内存对齐 - 476139183/Learning-iOS GitHub Wiki

结构体的对齐规则

编译环境：Xcode 11，64位，默认对齐数 k

（1).数据成员的对齐规则：
  1. 结构体的第一个成员放在 偏移量为0 的地址处。
  2. 其他成员放在 对齐数N 的整数倍地址处。不够整数倍的话，就偏移进行补齐。

对齐数取 编译器默认的值 和 该成员大小 的 min 值，在xcode上 64位默认值是8个字节。也就是k=8;

(2).数据成员位结构体时：
  1. 如果嵌套了结构体，那么结构体的 对齐数N 是自己内部成员的最大对齐数。

比如 struct a 存有 struct b，而 b 中有 char，int，doubule等元素，那么 b 的最大对齐数=max(1,4,8,k),也就是8个字节

(3). 结构体的整体对齐规则：

每一个成员按照上述规则对齐之后（除了第一个成员外，其他成员都有自己的对齐数），结构体本身也要进行对齐。

  1. 结构体的总大小就是 最大对齐数（含嵌套结构体的对齐数）的整数倍，不够的进行补齐。

结构体的最大对齐数 其实就是取出每一个成员的对齐数，取出其中最大的。

补充

每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。但是程序员可以通过预编译命令 #pragma pack(n) ，n=1,2,4,8,16 来改变这一系数，其中的 n 就是你要指定的“对齐系数”。

举例

struct StructOne {
    char a;         //1字节
    double b;       //8字节
    int c;          //4字节
    short d;        //2字节
} MyStruct1;

struct StructTwo {
    double b;       //8字节
    char a;         //1字节
    short d;        //2字节
    int c;         //4字节
} MyStruct2;

NSLog(@"%lu---%lu--", sizeof(MyStruct1), sizeof(MyStruct2));

打印结果为：24，16。

根据上述的规则分析，我们可以得出 StructOne 的内存分布图，如下：

1.png

具体分析:

默认对齐数是 8

  1. char a; //!放在结构体的首地址。偏移量为0
  2. double b; //! 计算出对齐数为 8，所以地址从下标8开始。中间进行空字节补齐
  3. int c; //! 计算出对齐数是4，下标16正好是4的倍数，所以不需要补齐，
  4. short d; //! 计算出对齐数是2，下标20正好也是2的倍数，所以不需要对齐
  5. 各数据总出占用内存是22。然后根据上述条件，得出最大对齐数是8，所以结构体本身也要进行对齐，所以实际分配内存为 24
代码验证

我们通过打印结构体的地址以及各个成员的地址，就能进行验证

  struct StructOne struct1;
  
  long a = (long)&struct1.a;
  long b = (long)&struct1.b ;
  long c = (long)&struct1.c;
  long d = (long)&struct1.d;
  
  NSLog(@"结构体地址---%ld,", (long)(&struct1));
  NSLog(@"成员地址-----%ld,%ld,%ld,%ld", a, b, c, d);

可以得到打印

结构体地址---140732852719888
成员地址-----140732852719888,140732852719896,140732852719904,140732852719908
  1. a 的地址 和结构体地址一样，说明偏移量为0。
  2. b 的地址和 a 的地址相差 8个字节。说明前面空了7个字节。
  3. c 的地址和b 相差 8个字节，且不需要补齐。
  4. d 的地址与c 相差了4个字节，大小也正等于 c 占用的大小，不需要补齐。此时，内存占用达到了 22；

最终结构体的分配的内存是 24，所以在 d 后面还补齐了2个空字节。这个也可以通过对结构体进行赋值，然后去堆栈里面查看来验证。

至于其他结构体的情况，这里不再表述。

为什么要进行内存对齐

内存对齐应该是编译器的管辖范围。而编译器会为程序中的每个数据单元安排在适当的位置上。 而实际下，编译器在分配的时候会进行内存对齐，很大的原因取决于你的CPU。

很多 CPU（如基于 Alpha，IA-64，MIPS，和 SuperH 体系的）拒绝读取未对齐数据。当一个程序要求这些 CPU 读取未对齐数据时，这时 CPU 会进入异常处理状态并且通知程序不能继续执行。举个例子，在 ARM，MIPS，和 SH 硬件平台上，当操作系统被要求存取一个未对齐数据时会默认给应用程序抛出硬件异常。所以，如果编译器不进行内存对齐，那在很多平台的上的开发将难以进行。

那么，为什么这些 CPU 会拒绝读取未对齐数据？是因为未对齐的数据，会大大降低 CPU 的性能。具体的我们得去分析CPU 的存取原理

CPU 存取原理

程序员通常认为内存印象，由一个个的字节组成。

但是，你的 CPU 并不是以字节为单位存取数据的。CPU把内存当成是一块一块的，块的大小可以是2，4，8，16字节大小，因此CPU在读取内存时是一块一块进行读取的。每次内存存取都会产生一个固定的开销，减少内存存取次数将提升程序的性能。所以 CPU 一般会以 2/4/8/16/32 字节为单位来进行存取操作。我们将上述这些存取单位也就是块大小称为（memory access granularity）内存存取粒度。

为了说明内存对齐背后的原理，我们通过一个例子来说明从未地址与对齐地址读取数据的差异。这个例子很简单：在一个存取粒度为 4 字节的内存中，先从地址 0 读取 4 个字节到寄存器，然后从地址 1 读取 4 个字节到寄存器。

当从地址 0 开始读取数据时，是读取对齐地址的数据，直接通过一次读取就能完成。当从地址 1 读取数据时读取的是非对齐地址的数据。需要读取两次数据才能完成。

而且在读取完两次数据后，还要将 0-3 的数据向上偏移 1 字节，将 4-7 的数据向下偏移 3 字节。最后再将两块数据合并放入寄存器。

对一个内存未对齐的数据进行了这么多额外的操作，这对 CPU 的开销很大，大大降低了CPU性能。所以有些处理器才不情愿为你做这些工作。

概括

  1. 平台原因，并不是所有的硬件平台都能访问任意地址的任意数据，当访问到某些非对齐的地址时，会拒绝访问，并且抛出 硬件异常
  2. 性能问题，数据结构（尤其是栈），应该尽可能的进行对齐。因为CPU在访问 非对齐内存时，需要访问两次，而对齐的内存，CPU只需要访问一次即可。

历史

最初的 68000 处理器的存取粒度是双字节，没有应对非对齐内存地址的电路系统。当遇到非对齐内存地址的存取时，它将抛出一个异常。最初的 Mac OS 并没有妥善处理这个异常，它会直接要求用户重启机器。实在是悲剧。

随后的 680x0 系列，像 68020，放宽了这个的限制，支持了非对齐内存地址存取的相关操作。这解释了为什么一些在 68020 上正常运行的旧软件会在 68000 上崩溃。这也解释了为什么当时一些老 Mac 编程人员会将指针初始化成奇数地址。在最初的 Mac 机器上如果指针在使用前没有被重新赋值成有效地址，Mac 会立即跳到调试器。通常他们通过检查调用堆栈会找到问题所在。

所有的处理器都使用有限的晶体管来完成工作。支持非对齐内存地址的存取操作会消减“晶体管预算”，这些晶体管原本可以用来提升其他模块的速度或者增加新的功能。

以速度的名义牺牲非对齐内存存取功能的一个例子就是 MIPS。为了提升速度，MIPS 几乎废除了所有的琐碎功能。

PowerPC 各取所长。目前所有的 PowerPC 都在硬件上支持非对齐的 32 位整型的存取。虽然牺牲掉了一部分性能，但这些损失在逐渐减少。

Power 是 1991 年，Apple、IBM、Motorola 组成的 AIM 联盟所发展出的微处理器架构。PowerPC 是整个 AIM 联盟平台的一部分，并且是到目前为止唯一的一部分。但苹果电脑自 2005 年起，将旗下电脑产品转用 Intel CPU。

现今的 PowerPC 处理器缺少对非对齐的 64-bit 浮点型数据的存取的硬件支持。当被要求从非对齐内存读取浮点数时，PowerPC 会抛出异常并让操作系统在软件层面处理内存对齐。软件解决内存对齐要比硬件慢得多。经过 IBM 在 PowerPC 测试，他们效率的差异大概在 4610%。

总结

在 iOS 开发中编译器会帮我们进行内存对齐。所以这些问题都无需考虑。但如果编译器没有提供这些功能，而且 CPU 也不支持读取非对齐数据，CPU 就会抛出硬件异常交给操作系统处理，从而产生 4610% 的差异。如果 CPU 支持读取非对齐数据，相比对齐数据，你还是要承担额外的开销造成的损失。诚然，这种损失绝不会像 4610% 那么大，但还是不能忽略的。

了解了这些后，当我们再声明结构体时就应该合理的安排内部数据的顺序，从而使其占用尽可能小的内存。你也许觉得这并没有什么卵用，但苹果在 Runloop 的源码中就使用了 _padding[3] 来手动对齐内存。

struct __CFRunLoopMode {
    CFRuntimeBase _base;
    pthread_mutex_t _lock;  /* must have the run loop locked before locking this */
    CFStringRef _name;
    Boolean _stopped;
    char _padding[3];
    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    CFMutableArrayRef _observers;
    CFMutableArrayRef _timers;
    //……
};

备注: Vc,Vs等编译器默认是#pragma pack(8)，所以测试我们的规则会正常；注意gcc默认是#pragma pack(4)，并且gcc只支持1,2,4对齐。套用三原则里计算的对齐值是不能大于#pragma pack指定的n值。

iOS 内存字节对齐

５分钟搞定内存字节对齐

⚠️ **GitHub.com Fallback** ⚠️