为何编译器不将数据对齐至不超过缓存行的最近2^N字节？

你观察得很准确——当像Foo这样的结构体数组跨越缓存行时，访问末尾元素会触发额外的缓存行读取，确实会影响性能。但C++默认的对齐规则（对齐至成员中最大类型的大小）是通用场景下的折中选择，直接对齐到缓存行并非适合所有情况，核心要在内存开销和性能收益之间做权衡：

1. 默认对齐是通用场景的最优解 #

绝大多数程序里，结构体的使用场景零散：要么是单个实例，要么是小容量数组，或者不会被频繁连续遍历的数组。这种情况下：

• 按最大成员大小对齐带来的内存浪费极小（比如你例子里的Foo仅占12字节，比32字节对齐省了20字节/实例），对内存占用非常友好。
• 如果默认就强制对齐到64字节，Foo的大小会直接膨胀到64字节，内存占用翻5倍多——对内存紧张的场景（比如嵌入式设备、存储大量小结构体的服务）来说，这种浪费可能引发更多的内存页交换，反而抵消了缓存优化的收益。

2. 缓存行对齐是针对性优化，而非默认选项 #

如果你的代码属于频繁连续遍历大型数组的性能敏感场景，C++完全支持手动指定缓存行对齐，比如用alignas关键字：

struct alignas(64) Foo {
  char a;
  long b;
  char c;
  // 编译器会自动填充剩余字节到64字节
};

这样6个Foo组成的数组总大小是384字节，刚好占6个完整的64字节缓存行，彻底避免拆分访问的问题。但这种优化是「按需使用」的——只有当你能明确感知到缓存行未命中是性能瓶颈时，才值得付出内存代价。

3. 如何判断要不要做缓存行对齐？ #

• 先测瓶颈：用性能分析工具（比如perf、VTune）定位，确认缓存行未命中是不是你程序的主要性能损耗点。如果你的代码大部分时间在做计算而非内存访问，对齐优化的收益可以忽略。
• 算成本收益：比如存储100万个Foo，默认对齐占12MB，64字节对齐占64MB——如果你的内存充足，且数组遍历的性能提升能覆盖内存占用的代价（比如不会因内存过载触发页换出），那就值得做；反之如果内存紧张，或者数组访问频率低，完全没必要。
• 注意伪共享：如果是多线程场景，缓存行对齐还要考虑避免伪共享（多个线程修改同一缓存行的不同成员）——这时候可能需要在结构体之间额外填充缓存行大小的空间，而非仅对齐结构体本身。

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