数组内存对齐与缓存行：分析变量存储对并发性能的影响

数组内存对齐这个话题，真正关键的不是简单地“对齐”，而是让每个核心变量各占一个缓存行，彻底隔离。这才是多线程并发性能提升的根本——避免伪共享（False Sharing）。说得更直白些：有没有对齐不是核心，是否让变量独占缓存行才是决定吞吐量的胜负手。

缓存行是64字节，不是可选配置

先说说一个基本事实：现代x86-64 CPU的L1/L2/L3缓存行标准大小是64字节。CPU每次从内存加载数据，不会只搬一个int，而是一口气读入完整的64字节。这意味着什么呢？

• 一个未对齐的int，起始地址是0x1003，它会横跨0x1000–0x103F和0x1040–0x107F两个缓存行，强制两次加载——性能立刻就下来了。
• 再看数组，里面的元素要是一个个char或std::atomic，默认紧密排列，多个线程同时改它们，很容易挤在一个缓存行里。
• ARM这类架构更敏感，未对齐访问可能直接报错；x86虽然兼容，但性能损耗也能达到数倍。

数组元素对齐不当会放大伪共享

典型的例子：环形缓冲区中的head和tail索引，常定义成两个std::atomic，紧挨着放在结构体开头：

struct RingBuffer {
  std::atomic head{0};
  std::atomic tail{0}; // 和head极大概率落在同一缓存行
  char data[1024];
};

线程A更新head，线程B更新tail，看起来各管各的，但CPU缓存一致性协议（如MESI）会让整个64字节的行标记为“已修改”，迫使另一个核失效本地副本并重新同步——这就是伪共享。从实测看，这种冲突能让吞吐量直接砍掉40%以上。

用alignas和填充控制数组/结构体内存布局

要解决这个问题，最简单的做法就是显式对齐和填充：

• 单个变量用alignas(64)卡死起始地址，比如alignas(64) std::atomic head;。
• 结构体里可以插入填充，在head和tail之间塞个char pad[64 - sizeof(std::atomic)];，强制间隔。
• 数组的话，比如高频更新的计数器数组，需要每个元素独占缓存行，就定义一个带alignas(64)的结构体，比如struct alignas(64) Counter { std::atomic val; } counters[1024];，编译器自动按64字节对齐每个元素起始位置。

对齐不是越严越好，要匹配访问模式

当然，对齐越严，浪费也越多。对小对象密集数组，不能盲目套用64字节对齐：

• 如果数组元素只被单一线程顺序读取（比如只读查找表），紧凑布局反而利用空间局部性更好，没必要刻意对齐。
• 要是涉及SIMD向量（比如__m256），那就得32字节对齐，alignas(32)比64更合适。
• 最好在编译期加个static_assert(alignof(T) >= 64, "T must be cache-line aligned");，防患于未然，避免运行时埋下隐患。