想象你是一名停车场的划线工。这个停车场叫“内存”，场地被划成一排排编号的车位。不过这里的车位规格五花八门：1 字节的“迷你车位”、2 字节的“小车位”、4 字节的“标准车位”、8 字节的“大车库”。规矩只有一条：一辆车必须停在编号恰好是它规格整数倍的位置——比如 8 字节的大巴士只能停在 0、8、16 号位，绝不能停在 4 号位压线。 这就是计算机内存的“对齐规则”。在 C/C++ 的结构体里，每个成员（int、char、double…）就像不同规格的车，编译器这个“停车场管理员”会先按规矩给它们划出对应规格的车位，再按顺序把数据“停”进去。如果下一辆车的规格要求当前位置不满足，管理员宁可在中间留下几个空车位（这叫 padding 填充），也不让车压线。 为什么这么死板？因为 CPU 这个“收费员”按字长（一次 16 或 32 字节）整块读取停车区，车停在线内它扫一眼就搞定；压线的车它得先读前半块再读后半块拼起来，慢得多。当然，画这么多空位也要付出代价——内存占用变大、结构体体积膨胀。好在管理员有“重新划线”的权限（#pragma pack），可以压缩车位，代价是访存效率下降。这篇文章就带你从划线工的第一视角，彻底搞懂内存对齐的规则、收益、代价与操控方法。

岗位关联

理解内存对齐，是掌握 C/C++ 结构体布局、网络协议设计与高性能推理引擎内存优化的基石。面试高频、调优必备，值得花 20 分钟彻底打通。

目录
  1. 可视化演示
  2. 1. 对齐基本概念：车必须停在“规格倍数”位
  3. 2. 结构体填充规则：空位就是这样留下的
  4. 3. 对齐效率价值：为什么管理员这么坚持划线
  5. 4. 对齐空间代价：空位也是要付租金的
  6. 5. 强制对齐控制：管理员重新划线
  7. 6. 跨平台对齐差异：每个城市的划线规矩不同
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示结构体内存布局、对齐与紧凑对比及访存效率分析的三模态交互动画。

本节配有交互动效（进入视口后自动加载，约 3KB）。

结构体内存布局 数据 填充 addr%align==0 编译器自动插入填充字节保证成员起始地址按自然对齐边界排列

1. 对齐基本概念：车必须停在“规格倍数”位

新来的划线工小张接到第一项任务：给一排新停车场划车位。老员工递给他一张规格表：迷你车占 1 格，小车占 2 格，标准车占 4 格，大巴占 8 格。规矩只有一条——每类车只能停在编号恰好是它规格整数倍的车位上，大巴绝不进 3 号位。小张记住了：这叫“对齐”。

在 C 语言的内存世界里，这条“编号整除”的规矩就是对齐规则。每个基本数据类型都有属于自己的“停车规格”，正式名称叫对齐值。char 的对齐值是 1，short 是 2，int 是 4，double 在常见 64 位平台上是 8。一个数据对象的起始地址，必须能被它的对齐值整除，否则计算机会拒绝把它放在那里。

编译器在给变量分配内存时，默认会遵守这条规则。当连续分配多个变量、或在结构体中依次安放成员时，如果当前空闲地址不满足下一个成员的对齐条件，编译器就跳过若干个字节，直到找到符合条件的地址。判断一个地址是否满足条件，标准就是下面的取模公式。

小张后来发现，只要车位编号是 4 的倍数，标准车停进去就四平八稳。要是编号 3，车头就压到隔壁区了。对齐判定本质上就是在问：这个编号除以规格，能不能除尽？除得尽，放行；除不尽，等下一个。

地址 mod 对齐值=0\text{地址} \bmod \text{对齐值} = 0
地址除以对齐值后余数为 0，说明这个地址是对齐值的整数倍，数据可以合法“停车”。
  1. 地址内存单元的编号，相当于停车位编号，通常用十六进制表示。
    地址\text{地址}
  2. 取模运算求地址除以对齐值后的余数，只关心“除不尽的部分”。
    地址 mod 对齐值\text{地址} \bmod \text{对齐值}
  3. 等于零判定余数为 0 说明地址可以被对齐值整除，满足对齐条件。
    地址 mod 对齐值=0\text{地址} \bmod \text{对齐值} = 0

2. 结构体填充规则：空位就是这样留下的

VIP 停车区要同时停一辆迷你车和一台标准车。小张按顺序来：迷你车先占了 1 号位，标准车需要编号是 4 的倍数，可下一位是 2 号，2、3 号都停不了，只能画上红色斜线标成“禁停区”，标准车从 4 号位开始停。这些禁停区就是传说中的 padding（填充）。

结构体里的填充完全同理。每个成员按声明顺序放进内存，编译器检查每个成员的起始偏移是否满足对齐，不满足就插入若干字节填充。成员放完还没结束：整个结构体的大小必须对齐到全体成员最大对齐值的整数倍，最后不足的部分叫尾部填充。

举例 struct { char a; int b; char c; }：a 在偏移 0；b 需要 4 对齐，偏移 1 不满足，填 3 字节后 b 放在 4~7；c 放在 8；最大对齐值是 4，总大小 9 向上补到 12。结构体大小的通用公式如下。

小张恍然大悟：一个街区画完后，总占地面积也得是最宽车位的整数倍，不然下一个街区就从歪歪扭扭的线开始了。所以结构体总大小，往往比成员大小之和大上一截。

sizeof(S)=⌈offsetof(mlast)+sizeof(mlast)Amax⁡⌉×Amax⁡\mathrm{sizeof}(S) = \left\lceil \frac{\mathrm{offsetof}(m_{\text{last}}) + \mathrm{sizeof}(m_{\text{last}})}{A_{\max}} \right\rceil \times A_{\max}
结构体总大小 = 末成员结束位置向上取整到最大对齐值的倍数。这就是尾部填充的来源。
  1. 末成员结束位置末成员起始偏移量加上它的字节大小，得到内容真正结束的字节数。
    offsetof(mlast)+sizeof(mlast)\mathrm{offsetof}(m_{\text{last}}) + \mathrm{sizeof}(m_{\text{last}})
  2. 最大对齐值结构体全体成员对齐值中的最大值，用于决定结构体作为整体的“停车规格”。
    Amax⁡A_{\max}
  3. 上取整到倍数把结束位置除以最大对齐值后向上取整，再乘回来，保证总大小是最大对齐值的整数倍。
    ⌈结束位置Amax⁡⌉×Amax⁡\left\lceil \frac{\text{结束位置}}{A_{\max}} \right\rceil \times A_{\max}

3. 对齐效率价值：为什么管理员这么坚持划线

为什么管理员宁可画这么多空位也不让车压线？收费员老李给出了答案：他每次收款只按“区”为单位清点，一个区固定 16 格，扫一眼 16 格一起登记。车在线内，一次搞定；车压着两个区的线，他得跑两个区分别清点，再回来拼接账目，慢一倍。

CPU 读取内存与老李清点如出一辙：处理器以字长为单位成块读取内存，64 位 CPU 一次取 8 字节，再配合缓存行（通常 64 字节）批量搬运。数据起始地址恰好落在块边界上，读一次就是全部；否则数据横跨两个块，就要两次读内存再加拼接。

以字长 8 字节为例，一个 8 字节的 double 从地址 6 开始，会横跨 0~7 和 8~15 两块，需两次访存；从地址 8 开始则一次完成。通用访存次数公式如下。

小张终于理解了红线的意义：表面看是死板，实际上是给收费员省跑腿。对齐访问就是“块内直达”，未对齐访问就是“跨块拼图”。多花点空地买速度，这笔账大多数场景都很划算。

访存次数=⌈(a mod w)+sw⌉\text{访存次数} = \left\lceil \frac{(a \bmod w) + s}{w} \right\rceil
其中 a 是起始地址，w 是字长（字节），s 是数据长度。对齐时 a mod w = 0，且 s ≤ w，结果恒为 1 次。
  1. 起始地址字内偏移地址除以字长后的余数，表示数据在第一个字内的起步位置。压线越深，这个值越大。
    a mod wa \bmod w
  2. 数据总跨度起步偏移加上数据长度，表示从第 0 字节数到数据末端一共跨了多少个字节。
    (a mod w)+s(a \bmod w) + s
  3. 上取整得访存次数把总跨度除以字长后向上取整，即这个数据要占用几个“清点区”。
    ⌈(a mod w)+sw⌉\left\lceil \frac{(a \bmod w) + s}{w} \right\rceil

4. 对齐空间代价：空位也是要付租金的

月底盘点，小张发现 VIP 区画了 12 格，真正停车的只有 6 格，一半是红色斜线禁停区。物业说：租金按划线面积收，空位照样交钱。他第一次意识到，每条对齐线背后都是白花花的银子。

结构体的填充字节不保存任何数据，却同样消耗内存。一个结构体占 12 字节，其中只有 6 字节是真实成员，浪费率 50%。当程序里存放一万个这样的结构体数组，多出的 6 万字节就是纯开销。好在布局顺序在自己手里，重新排列成员顺序，常常能把浪费减到最小。

比如 struct { char c; char a; int b; } 把两个 char 放一起，再放 int，同样是三个成员，占 8 字节而不是 12 字节。我们可以用量化公式衡量一个结构体的空间浪费程度。

小张的优化方案是把同规格的车停进同一个片区，大小车分开，禁停区自然变少。写结构体也一样：把对齐值大的成员往前提，把小的聚在一起，就能用最少的空位满足所有对齐要求。

浪费率=1−∑isizeof(mi)sizeof(S)\text{浪费率} = 1 - \frac{\displaystyle\sum_{i} \mathrm{sizeof}(m_i)}{\mathrm{sizeof}(S)}
用 1 减去真实数据字节和占总大小的比例，剩下的就是填充字节占的比例。
  1. 成员字节总和所有成员类型大小的总和，代表“实际载客量”。
    ∑isizeof(mi)\sum_{i} \mathrm{sizeof}(m_i)
  2. 结构体总大小包含填充后的整体占用，代表“划线的总面积”。
    sizeof(S)\mathrm{sizeof}(S)
  3. 求差得浪费比例用 1 减去数据占比，得到 padding 占总空间的百分比。
    1−数据量总大小1 - \frac{\text{数据量}}{\text{总大小}}

5. 强制对齐控制：管理员重新划线

一天物业突然要求压缩车位规模。小张拿来一台新划线机，输入"1"，所有车位按 1 格重新画，迷你车、标准车全挤在一起，一个空位都不留。他提醒自己：车是停密了，但收费员清点每辆车时都得跨好几个区去拼账。

这台“划线机”在 C/C++ 里就是预处理指令 #pragma pack(n)。它把全体成员的有效对齐值统一限制为“自然对齐值与 n 的较小值”。n = 1 时完全取消填充，成员紧挨排列；n = 2 时 int 只按 2 字节对齐。GCC/Clang 还提供 __attribute__((packed)) 对单个结构体生效，写法更局部。

有效对齐值的计算是一个简单的 min 函数。

pack(1) 换来了极致的紧凑布局，代价是每个成员都可能错位，访存效率下降。小张的结论是：划线机不是日常工具，只在处理外部协议、文件格式这类必须与字节流严格对齐的场景才拿出来。

有效对齐值=min⁡(自然对齐值,n)\text{有效对齐值} = \min(\text{自然对齐值}, n)
packing 只会缩小对齐、不会放大对齐。n 通常取 1、2、4、8、16，代表把对齐上限卡到多少字节。
  1. 自然对齐值编译器按类型默认推导出的对齐值，如 int 的 4。
    自然对齐值\text{自然对齐值}
  2. 取两者较小值min 表示 pack 只负责“收紧”，不能把本来 4 对齐的 int 放宽到 8。
    min⁡(自然对齐值,n)\min(\text{自然对齐值}, n)
  3. 代入地址判定用有效对齐值替代原对齐值参与取模判断，得到新布局规则。
    地址 mod min⁡(自然对齐值,n)=0\text{地址} \bmod \min(\text{自然对齐值}, n) = 0

6. 跨平台对齐差异：每个城市的划线规矩不同

小张被派到外地出差，发现隔壁城市的划线规矩完全不一样：同样的标准车，自己城市规定 4 格，那边规定 2 格；自己城市大巴 8 格，那边 4 格。他重新画了一版图纸发回总部，结果总部按老规矩停车，车全部错位。

跨平台的内存对齐就是这样。32 位与 64 位环境下，指针、long、double 等类型的大小和对齐值不同，同一结构体在两平台编译出的成员偏移和总大小可能完全不同。ABI（应用程序二进制接口）像是每座城市的停车管理条例，决定了默认对齐规则；但跨平台传输结构体原始内存时，不能假设两者布局一致。

struct { char c; double d; } 在 64 位 Linux 下 double 对齐 8，大小 16；在 32 位环境下 double 对齐常为 4，大小可能 12。差异来源就是填充。

最稳妥的做法不是让两个城市共用一套图纸，而是把每辆车的信息都写到统一格式的卡片（显式序列化）上，到了目的地再按卡片重新停。这也是为什么现代网络通信几乎都用 protobuf、FlatBuffers 这类结构化序列化格式，而不是直接拷贝结构体内存。

Δ=size64−size32\Delta = \mathrm{size}_{64} - \mathrm{size}_{32}
Δ 表示同一结构体在 64 位与 32 位环境下的大小差，本质上是两套填充规则造成的字节数差异。
  1. 两平台结构体大小同一结构体分别在 64 位与 32 位环境中的 sizeof 值。
    size64,size32\mathrm{size}_{64}, \mathrm{size}_{32}
  2. 求差两者相减，得到因对齐规则不同而多出的字节数。
    size64−size32\mathrm{size}_{64} - \mathrm{size}_{32}
  3. Δ 的物理意义成员含 8 字节类型时，64 位通常比 32 位填入更多 padding。
    Δ=size64−size32\Delta = \mathrm{size}_{64} - \mathrm{size}_{32}

AI 应用场景

场景1：AI 服务间的请求消息序列化

阶段：模型服务通信与请求解析

解决的问题：AI 服务之间传递特征向量、模型元数据时，如果直接发送 C 结构体内存，不同语言和平台的布局不一致会导致解析错乱。就像两座城市划线规矩不同，A 市的原始图纸到了 B 市全部错位。

具体案例：某推理服务用 C++ 编写，网关用 Go 实现，两端定义同一份请求结构体 FeatureVector { int id; float value[128]; }。未统一对齐策略时，C++ 按 8 字节对齐、Go 按自身规则排列，二进制解析错位，特征值全是噪声。切换为 protobuf 消息定义后，跨端字节流完全一致，解析稳定。

场景2：高性能推理引擎的张量内存对齐

阶段：模型推理前处理与算子执行

解决的问题：张量数据在内存中按行优先存储，每行需要按向量指令宽度（如 16 或 32 字节）对齐，否则 SIMD 加载效率暴跌。相当于收费员一次能清点 32 格，结果车全压线，他只能分多次跑。

具体案例：某算子库在分配特征矩阵缓冲区时，用 aligned_alloc(32, ...) 保证行首地址 32 字节对齐，并计算每行 padding 到 32 的倍数，使 AVX-512 一条指令读取整行数据。实测推理吞吐提升约 15%。

场景3：嵌入式 AI 芯片的硬件寄存器映射

阶段：端侧部署与驱动开发

解决的问题：NPU 寄存器组要求按硬件手册的精确偏移访问，结构体映射寄存器时不能有 padding 错位。就像按物业老图纸精确还原车位，多画一个空位整个设备都会失灵。

具体案例：某端侧 NPU 的寄存器描述结构体用 __attribute__((packed)) 确保每个寄存器偏移与手册一致，配合 volatile 访问避免编译器优化，直接通过结构体改写寄存器控制 AI 加速器启动。

Python 演示

python43 行
# 内存对齐演示: 用 ctypes 模拟 C 结构体的填充与打包import ctypesfrom ctypes import c_char, c_int32 class AutoAligned(ctypes.Structure):    # 按编译器默认自然对齐排列 (int 的 4 字节对齐)    _fields_ = [        ("a", c_char),   # 1 B        ("b", c_int32),  # 4 B, 前面需要补 3 B padding        ("c", c_char),   # 1 B, 尾部还要补 3 B padding    ] class Packed1(ctypes.Structure):    # 使用 _pack_ = 1 强制 1 字节对齐, 取消全部填充    _fields_ = [        ("a", c_char),        ("b", c_int32),        ("c", c_char),    ]    _pack_ = 1  def dump(name, st):    n = ctypes.sizeof(st)    buf = (ctypes.c_ubyte * n)()    ctypes.memmove(buf, ctypes.addressof(st), n)    hexs = " ".join(f"{v:02x}" for v in buf)    print(f"{name:>8}: size={n:>2}, layout=[{hexs}]")  if __name__ == "__main__":    aligned = AutoAligned()    aligned.a = b"X"          # 0x58    aligned.b = 0x04030201    # 小端存储, 写入后字节序为 01 02 03 04    aligned.c = b"Y"          # 0x59     packed = Packed1()    packed.a = b"X"    packed.b = 0x04030201    packed.c = b"Y"     dump("Aligned", aligned)    dump("Packed", packed)
目的：用 Python 的 ctypes 库模拟 C 结构体，直观对比自然对齐与 pack(1) 两种布局的字节流差异。运行后能看到 Aligned 大小 12 字节、两段红色填充；Packed 大小仅 6 字节、成员紧挨。
  1. class AutoAligned(ctypes.Structure)定义一个等价于 C 结构体的类，ctypes 会按 C 规则自动对齐。
  2. ("b", c_int32)4 字节 int 成员，自然对齐值为 4，前面只放了 1 字节 char，编译器需要补 3 字节。
  3. _pack_ = 1等价于 C 的 #pragma pack(1)，强制 1 字节对齐取消全部填充。
  4. ctypes.sizeof(st)读取结构体总字节数，等价于 C 的 sizeof。
  5. ctypes.memmove(buf, ctypes.addressof(st), n)把结构体内存字节原样拷贝出来，方便打印布局。
  6. aligned.b = 0x04030201小端存储低位在前，写入后字节序为 01 02 03 04。
  7. f"{v:02x}"把每个字节格式化为两位十六进制，肉眼可见 padding 位置。

常见误区

误区我数了成员：char 是 1，int 是 4，char 是 1，加一起 6，所以 sizeof 应该是 6 吧？

正解sizeof 是 12 而不是 6。因为前一个 char 之后插入了 3 字节 padding 让 int 对齐（起始地址为 4 的倍数），尾部还要补 3 字节让总大小是最大对齐值 4 的倍数。停车场的“划线面积”包含禁停区，哪怕没有车停也要计入。

为何常见：直觉上认为内存是连续塞满的字节流，没意识到“地址必须被对齐值整除”这条硬约束。

误区把结构体打包得越小，缓存里能放下更多对象，性能一定更好！

正解pack(1) 只省内存，但所有成员都可能错位，CPU 需要额外拼接才能读写。在 x86 上性能下降，在某些 ARM/DSP 上直接触发硬件异常。它是“用时间换空间”，只有当内存带宽或容量是瓶颈、或协议需要固定布局时才值得用。

为何常见：把“占用空间小”等同于“性能好”，忽略了访存效率这条更重要的路径。

误区把所有成员按从大到小排序，结构体就没 padding 了。

正解成员重排能减少填充，但不一定能完全消除。若 8 字节和 4 字节成员数量非对称，比如 double + char + int，即使先放 double，后面 int 前仍可能插入 0~4 字节。此外重排会改变字段偏移，影响跨语言映射代码的偏移约定。

为何常见：看到“重排优化”的典型例子就总结成通法，忽略对齐是基于整除规则、并非完全可逆的事实。

误区我都打成 pack(1) 了，字节流总该在所有机器上都是同一个样了吧？

正解pack(1) 只消除了结构体内部填充，还有三个变量：大小端字节序、基础类型宽度（32 位下 long 是 4 字节，64 位下是 8 字节）、char 的符号性。协议字段宽度和字节序仍需另行约定。同是“按 1 格停车”，A 城车位编号方向和 B 城相反，数据依然对不上。

为何常见：把“对齐”当成跨平台一致性的唯一障碍，忽略了字节序与基础类型宽度。

误区int 是 4 字节，所以它的对齐值一定是 4。

正解默认情况下大多类型对齐值与大小相同，但这是 ABI 约定而非推导结果。32 位平台 double 对齐常为 4，64 位为 8；某些 ARM 处理器还要求 double 8 字节对齐。类型对齐值可以用 alignof 查询。

为何常见：从 char=1、int=4 等例子总结出简单规律，没意识到 ABI 的平台相关性。

面试题

Q1. 结构体 struct { char a; int b; } 在常见 64 位平台（int 对齐 4）下的 sizeof 是？

单选题 · easy

  • A.5 字节
  • B.6 字节
  • C.8 字节← 正确答案
  • D.12 字节

答案：C。char a 占偏移 0，int b 需要 4 对齐，偏移 1 不满足，编译器插入 3 字节填充，b 占 4~7，总大小 8，且 8 是最大对齐值 4 的倍数，无需尾填充。选 C。

Q2. 下列关于“对齐值”的说法，正确的是？

单选题 · easy

  • A.等于类型字节大小
  • B.由ABI与编译器决定← 正确答案
  • C.数值越大速度越快
  • D.所有类型统一一致

答案：B。默认多数类型对齐值等于 sizeof，但 double 等类型在 32/64 位平台对齐不同，所以 A 过于绝对；对齐值由 ABI 和编译器共同决定，选 B。C 错在对齐值只是硬件友好的前提，不是越大越快；D 错在类型对齐值各不相同。

Q3. #pragma pack(1) 对结构体的作用是？

单选题 · mid

  • A.将结构体对齐值设为 1← 正确答案
  • B.按成员大小自动重排序
  • C.让结构体体积缩小一倍
  • D.自动删减多余数据成员

答案：A。pack(1) 把所有成员的有效对齐值限制为 1，等价于取消全部填充，选 A。B 是成员重排不是 pack；C 说体积缩小一倍太绝对；D 是错误理解，pack 不删除任何成员。

Q4. 结构体 struct { char c; double d; } 在 64 位 Linux（double 对齐 8）下的 sizeof 是？

单选题 · mid

  • A.10 字节
  • B.12 字节
  • C.16 字节← 正确答案
  • D.9 字节

答案：C。char c 在偏移 0，double d 需要 8 对齐，偏移 1~7 全部填充，d 占 8~15，总大小 16，且 16 是最大对齐值 8 的倍数，选 C。这就像大巴进驻后，前面 7 个迷你车位全变禁停区。

Q5. 为什么未对齐的数据访问比较慢？

单选题 · easy

  • A.编译器会直接报错终止
  • B.CPU需要多次访存拼接← 正确答案
  • C.未对齐数据占内存更多
  • D.缓存命中率必然降为零

答案：B。CPU 按字长成块读取内存，未对齐数据横跨两个块，需要两次访存再拼接，选 B。A 错在多数平台不会因此报错；C 错在未对齐不改变数据占用；D 的“必然为零”过于绝对。

Q6. 结构体 struct { int a; char b; short c; } 在 int/short 对齐分别为 4/2 的平台上，sizeof 为？

单选题 · hard

  • A.8 字节← 正确答案
  • B.12 字节
  • C.10 字节
  • D.7 字节

答案：A。int a 占 0~3，char b 占 4，short c 需要 2 对齐，当前偏移 5 不满足，插入 1 字节填充，c 占 6~7，总大小 8，是最大对齐值 4 的倍数，选 A。12 字节是误以为 short 也补齐到 4 的结果。

Q7. 下列哪些手段可以影响结构体成员的对齐布局？

多选题 · mid

  • A.调整成员的声明顺序← 正确答案
  • B.使用 #pragma pack(n)← 正确答案
  • C.修改成员变量的名称
  • D.加 packed 属性声明← 正确答案

答案：ABD。成员声明顺序影响中间填充的位置，pack(n) 统一限制对齐上限，packed 属性对单个结构体取消填充，三者都能改变布局，选 A、B、D。C 改名不改变类型与顺序，不影响任何字节排布。

Q8. 跨平台直接使用结构体进行网络传输的风险包括？

多选题 · hard

  • A.不同平台成员偏移不同← 正确答案
  • B.大小端字节序可能不同← 正确答案
  • C.基础类型宽度可能不同← 正确答案
  • D.编译器自动转网络字节序

答案：ABC。不同平台 ABI 不同导致成员偏移与填充不同，大小端影响多字节字段的字节序，long 等基础类型宽度在 32/64 位下不同，三者都是风险，选 A、B、C。D 错在编译器不会自动做网络字节序转换，需手动处理。

Q9. 已知 struct { char a; int b; char c; } sizeof 为 12，将成员重排为 struct { int b; char a; char c; } 后，sizeof 最可能为？

单选题 · mid

  • A.12 字节
  • B.8 字节← 正确答案
  • C.6 字节
  • D.10 字节

答案：B。int b 占 0~3，char a 占 4，char c 占 5，内容结束于 6，向上对齐到最大对齐值 4 的倍数得 8，选 B。这就是“同规格车停一起、禁停区最少”的重排优化。

Q10. 关于结构体尾部填充（tail padding），下列说法正确的是？

多选题 · extreme

  • A.保证总大小是最大对齐倍数← 正确答案
  • B.数组元素逐个对齐的关键← 正确答案
  • C.某些优化可复用尾填充← 正确答案
  • D.取消尾填充不影响大小

答案：ABC。尾部填充让 sizeof 是最大对齐值的整数倍，选 A；数组元素地址 = base + i × sizeof，只有 sizeof 是对齐倍数，每个元素起始地址才能自动对齐，选 B；编译器在基类优化等场景可能复用尾填充，选 C。D 错在取消尾填充会直接改变 sizeof 结果。