数组的物理连续性决定缓存行利用效率：连续布局使多个元素共存于同一64字节缓存行，顺序访问时前16个int可一次加载、高命中；链表则因节点分散导致频繁跨行加载、命中率骤降；二维数组须行优先遍历以匹配内存布局，列优先易引发大量cache miss；结构体应alignas(64)对齐避免跨行和伪共享。
数组的物理连续性直接决定了 CPU 缓存行能否被高效利用。关键不是“有没有缓存”，而是“一次加载能用多久”——连续布局让多个元素挤进同一缓存行，大幅减少内存访问次数。
缓存行加载机制与数组连续性的匹配关系
CPU 每次从内存取数据，不是按字节、也不是按变量，而是按固定大小的块（通常是 64 字节）整块搬入缓存。数组在内存中是挨着排的，比如 int 类型占 4 字节，那么一个缓存行就能装下 16 个连续 int 元素。当你顺序访问 arr[0]、arr[1]、arr[2]……前 16 个元素大概率已在第一次加载时全部进缓存，后续访问基本不触发新内存读取。
- 反例：链表节点分散分配，哪怕只存两个指针（16 字节），每次跳转都大概率跨缓存行，造成大量空载加载（64 字节只用 16 字节）
- 实测现象：遍历百万级 int 数组，L1 缓存命中率常超 90%；同规模链表遍历，命中率可能低于 20%
二维数组遍历时的行优先 vs 列优先差异
二维数组本质仍是线性存储，C/C++ 默认按行优先（row-major）排布：a[0][0]、a[0][1]、a[0][2]……a[0][n-1]、a[1][0]……因此访问模式必须匹配这个物理顺序，才能让缓存行“物尽其用”。
-
推荐写法（行优先）：
for (i=0; i<N; i++) for (j=0; j<N; j++) a[i][j] = ...—— 每次内层循环都在同一缓存行内滑动，预取器能稳定跟上 -
低效写法（列优先）：
for (j=0; j<N; j++) for (i=0; i<N; i++) a[i][j] = ...—— 每次 i 变化都跳到下一行首地址，间隔为 N×sizeof(int)，极易导致每步都 cache miss - 实验显示：对 2048×2048 的 int 数组，列优先遍历耗时可能是行优先的 2–8 倍
结构体数组与缓存行对齐的实际影响
当数组元素是结构体时，单个结构体大小若未对齐或跨缓存行边界，会放大浪费。例如一个 30 字节的结构体，在默认填充下可能被编译器扩展到 32 字节，但若起始地址偏移为 50，则它横跨两个缓存行（50–63 和 0–16），每次读取都要拉两次 64 字节。
- 解决方案：用
alignas(64)强制结构体按 64 字节对齐，确保每个实例独占（或至少不跨）缓存行 - 典型场景：高频消息队列、实时行情结构体、并发计数器——热字段集中放在结构体头部，并填充至 64 字节，可避免伪共享和跨行读取
- 不加对齐时，1024 个结构体可能引发上千次额外内存访问；对齐后，访问次数趋近于结构体数量
优化方向不是“换算法”，而是“适配硬件”
很多性能瓶颈不在计算逻辑，而在数据怎么躺在内存里、怎么被读出来。数组连续性本身不提供新功能，但它把“硬件预取 + 缓存行加载”这个机制真正激活了。
- 避免动态分配小对象组成的容器（如 vector<unique_ptr<T>>），改用 pool 分配或 flat 容器
- 批量处理时尽量保持 stride = 1（单位步长），避免跳跃式索引或间接寻址
- 对超大数组，考虑分块（blocking / tiling）策略，让每个块大小贴近 L1 或 L2 缓存容量，提升重用率
