java二维数组行访问高效而列访问低效，源于“数组的数组”内存布局导致行内连续、列间离散；优化列访问应转置存储、一维展平、分块处理或使用堆外内存对齐。
Java 规则二维数组（即每行长度相同）的行访问天然高效，列访问天然低效——这不是写法问题，而是由其“数组的数组”内存布局决定的。优化重点不在怎么加速列遍历，而在如何让列操作回归缓存友好的连续访存模式。
行访问为什么快：底层连续 + 缓存行友好
规则二维数组如 int[][] mat = new int[1000][50]，外层数组存 1000 个引用，每个引用指向一个独立分配的 int[50]。虽然整块不连续，但每一行内部元素在内存中是连续的，长度 50 × 4 字节 = 200 字节，刚好跨越 3–4 个 64 字节缓存行。
- 行优先遍历时（
i外层、j内层），地址每次 +4 字节，高度连续，L1 缓存命中率可达 95% 以上 - JIT 编译器能自动消除边界检查、展开循环、向量化加载（尤其当
j范围固定且可预测时） - 无需额外对齐干预，只要列数合理（如 16、32、64），末尾元素不易跨缓存行
列访问为什么慢：随机跳转 + 缓存行撕裂
列访问（j 固定、i 变化）意味着每次读取 mat[i][j] 都要先解引用外层数组得到第 i 行首地址，再偏移 j × 4 字节。而各行物理地址彼此无关，可能分散在堆不同区域。
- 相邻两次访问（
i和i+1）的地址差约为整行大小（如 200 字节），大概率跨多个缓存行甚至内存页 - 实测显示：对 1000×1000 的
int[][]做单列求和，耗时是等价行求和的 5–7 倍 - 即使把
length提到循环外、用局部变量缓存引用，也无法缓解根本性的空间局部性缺失
真正有效的列访问优化路径
不要试图“优化列循环”，而应重构数据或访问方式，使其本质变成行访问：
-
转置存储：若业务长期按列统计（如每列最大值、均值），初始化时就构建转置副本
int[][] transposed = new int[cols][rows]，后续按行遍历即可 -
一维展平 + 列映射：用
int[] flat = new int[rows * cols]存储，逻辑列j对应物理位置flat[j], flat[j + cols], flat[j + 2*cols], ...—— 这仍是连续步长访问，JIT 可识别为 stride 模式并预取 -
分块列处理：将列切分为块，每块含 8 或 16 行（匹配缓存行容纳的
int数量），在块内顺序访问，减少 TLB 和缓存行失效频次 -
用
java.nio.FloatBuffer或ByteBuffer：分配堆外直接内存，配合order(ByteOrder.nativeOrder())，可获得真正连续、对齐可控的底层存储
缓存行对齐的关键细节
即使使用一维展平，若逻辑行宽不是缓存行字节数的整数倍，仍会引发“末尾分裂”——最后一个元素落在新缓存行开头，而前一行刚被换出。
- 对
int（4 字节），缓存行 64 字节 → 每行最多放 16 个元素；建议列数向上对齐到 16 的倍数（如 48→48，49→64） - 填充方式：声明时多分配（
new int[rows * paddedCols]），业务逻辑中忽略填充位，或用封装类屏蔽细节 - 注意：Java 不提供
alignas，但 JVM 在分配大数组时通常会自然对齐到 8 或 16 字节；严格 64 字节对齐需借助Unsafe或堆外内存
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
