System.arraycopy本身不支持步长与缓存行优化，真正的优化在于自定义循环中按64字节缓存行对齐起始地址、设置整块大小为64倍数、结合分块与步长访问以提升L3命中率并减少伪共享。
System.arraycopy 本身不支持步长，也不感知缓存行；所谓“根据三级缓存行优化步长”，实际是指在自定义循环或分块处理中，主动适配 64 字节缓存行大小（主流 x86 架构），以提升 L3 缓存命中率、减少伪共享与跨行访问开销。关键不在“用 arraycopy 设步长”，而在于设计访问模式时让每次内存操作尽量对齐、连续、局部。
明确缓存行边界与数据粒度关系
现代 CPU 的 L3 缓存行通常是 64 字节。若元素为 int（4 字节），则一行可存 16 个；若为 long（8 字节），则存 8 个。因此： - 步长（stride）若为 16 的倍数（如 16、32、64），易导致每次访问都落在同一缓存行起始位置，但若起始地址未对齐，仍可能跨行； - 更稳妥的是让**处理块大小**（block size）是 64 的整数倍，例如每次处理 1024 字节（16 个 int 或 8 个 long），使整个块大概率驻留在 L3 中，降低驱逐频率。
按缓存行对齐分配与访问起始点
数组起始地址是否 64 字节对齐，直接影响首块是否跨行： - 普通 new int[1024] 不保证对齐，可通过 Unsafe.allocateMemory + align 分配堆外内存，或使用 ByteBuffer.allocateDirect() 配合 address 对齐； - 若无法控制分配，可在循环中跳过前若干元素，使首个访问索引满足 index × elementSize % 64 == 0； - 示例：int 数组，希望首访从 64 字节对齐处开始 → 起始索引 i₀ = (64 − (arrayAddress % 64) / 4) % 16，再从此开始 stride 访问。
分块+步长组合策略（Blocking + Strided Access）
纯大步长遍历（如每 64 个元素取 1 个）会严重破坏空间局部性。应结合分块来缓解： - 将源数组划分为若干 block，每个 block 大小设为 512–2048 字节（即 8–32 个 cache line）； - 在每个 block 内，按所需步长顺序访问（如 STEP=8），确保访问集中在少数几个缓存行内； - 完成一个 block 后再跳到下一个，避免长距离跳跃导致 L3 预取失效。
- 避免临界步长：如矩阵列宽为 512（512×4=2048 字节，恰为 32 行），易引发缓存组冲突；列宽改用 513 可打散分布
- 多线程场景下，各线程处理的变量须独占缓存行：用 @Contended（Java 8+）或手动 padding 至 64 字节对齐
- 对只读场景，可启用 JVM 参数 -XX:+UseSuperWord 促进向量化，间接提升 cache line 利用率
验证与调优建议
优化效果不能仅靠理论推导，需实测： - 使用 perf stat -e cache-references,cache-misses,L1-dcache-loads,LLC-loads 等指标观察 L3 命中变化； - 对比不同 block size（如 64/256/1024 字节）和 stride（如 4/8/16）组合下的吞吐量； - 注意：JIT 编译可能重排循环、消除冗余加载，开启 -XX:+PrintAssembly 可确认生成指令是否缓存友好。
不复杂但容易忽略：对齐起点、控制块大小、避开临界步长——这三点落地后，L3 缓存效率常有 15%~40% 提升。
