数据对齐应遵循数据类型还是CPU缓存行大小？

我们知道数据通常会按自身类型对齐，比如32位的int按4字节对齐，这样能提升处理器加载/存储数据的效率。但还有以下疑问：

• 缓存行对齐何时适用？
• 若x64平台缓存行大小为64字节，是否需要将每个数据都按64字节对齐？这看起来会造成内存浪费。
• 数据类型对齐和缓存行对齐有何关联？
• 既然CPU与缓存行始终以64位为单位交互，为何数据类型对齐仍很重要？

一、缓存行对齐的适用场景 #

缓存行对齐不是处处都要用，主要在多线程并发访问共享数据或者需要频繁连续访问的批量数据场景下才需要重点考虑：

• 多线程场景：如果多个线程各自访问的变量刚好挤在同一个缓存行里，会触发"伪共享"——一个线程修改变量导致整个缓存行失效，其他线程就得重新从内存加载，严重拖慢性能。这种时候把每个线程独立访问的变量放到单独的缓存行（也就是按64字节对齐），就能避免伪共享。
• 批量数据访问：比如数组、结构体数组这类需要连续遍历的数据，按缓存行对齐后，CPU一次加载缓存行就能覆盖更多有效数据，减少内存访问次数，提升缓存命中率。

二、x64下不需要给每个数据都做64字节对齐 #

完全没必要这么干，确实会造成巨大的内存浪费。只有前面说的那些特殊场景（比如避免伪共享、优化批量访问）才需要针对性地给特定数据做缓存行对齐，普通的单个变量（比如单独的int、float）按自身类型对齐就足够了，没必要强行凑64字节。

三、数据类型对齐和缓存行对齐的关联 #

这俩是层级不同的对齐要求，本质都是为了提升CPU访问效率，但适用范围和粒度不一样：

• 数据类型对齐是基础要求：是CPU硬件层面的硬性要求（部分架构甚至不支持非对齐访问，访问会直接报错；x64虽然支持，但非对齐访问会触发额外的内存操作，速度变慢），针对的是单个数据类型的最小访问单元。
• 缓存行对齐是进阶优化：是基于缓存机制的性能优化手段，针对的是缓存的最小加载单元（64字节），只有在特定场景下才需要启用，属于"锦上添花"的优化，不是必须的基础要求。
  而且，缓存行对齐的前提是满足数据类型对齐——比如你要给一个结构体做缓存行对齐，结构体里的每个成员首先得按自身类型对齐，整个结构体再凑到64字节的倍数，不然基础的访问效率都没法保证。

四、为什么CPU按64位交互，数据类型对齐仍重要 #

首先要明确：CPU和缓存行按64位（8字节）交互，不代表CPU只能处理8字节的数据。不同的数据类型有不同的访问宽度——比如int是4字节，short是2字节，char是1字节。
如果数据没按类型对齐，比如一个int跨了两个64位的内存块，CPU要加载这个int就得读两次内存（先读第一个块的后4字节，再读第二个块的前4字节），然后还要把这两部分拼接起来才能用，这比直接读一个对齐好的int多了好几个步骤，速度自然慢。
就算是64位的long long，如果没对齐到8字节，同样会触发类似的额外操作，而且部分老架构甚至不允许这种非对齐访问，直接抛出异常。所以数据类型对齐是保证单个数据访问效率的基础，和CPU与缓存的交互粒度不冲突。

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