Java数组能实现O(1)下标访问，根本原因是其元素在堆内存中连续存储，JVM通过“基地址 + i × 元素大小”公式直接计算内存地址，无需遍历或查找，配合编译期已知的固定元素大小与硬件级快速算术运算，实现常数时间定位。
Java 数组能实现 O(1) 时间复杂度的下标访问，根本原因在于其内存连续布局和线性寻址机制——不是靠“查表”或“哈希”，而是靠一道简单算术公式直接算出地址。
数组在内存中怎么排？
Java 数组对象本身存于堆中，包含两部分：
- 对象头（约12字节）：存储类信息、GC标记、锁状态等元数据；
- 元素区（连续空间）：从紧随对象头之后开始，按顺序存放所有元素，每个元素大小固定（如 int 占 4 字节，long 占 8 字节）。
例如：int[] arr = new int[5];，假设对象头起始地址为 0x1000，则：
- arr[0] 地址 = 0x1000 + 12（跳过对象头） = 0x100C
- arr[1] 地址 = 0x100C + 4 = 0x1010
- arr[i] 地址 = 0x100C + i × 4
这个计算由 JVM 在运行时瞬间完成，无需遍历、无需查找。
立即学习“Java免费学习笔记（深入）”；
下标访问为什么快？关键就在这条公式
JVM 对 arr[i] 的处理本质是：
其中：
- base_address 是元素区首地址（对象头后偏移量固定）；
- element_size 是编译期已知的常量（int=4，double=8，引用类型一般为 4 或 8 字节，取决于压缩指针开关）；
- i 是整数索引，参与一次乘加运算。
整个过程仅需 CPU 几个周期——现代处理器甚至能在一个指令周期内完成地址计算并加载数据。
注意：JVM 还会做边界检查（i >= 0 && i ），但该检查被高度优化，通常不构成性能瓶颈；真正影响性能的是越界导致的 <code>ArrayIndexOutOfBoundsException 异常抛出（涉及栈展开，开销大），所以生产环境务必避免越界写法。
对比非连续结构，差距在哪？
对比 ArrayList（底层封装了 Object[]）：
- ArrayList.get(i) 最终仍调用数组下标访问，所以随机读性能几乎与原生数组一致；
- 但 ArrayList 多一层方法调用、多一次 size 检查、且泛型擦除后存在类型转换隐含开销（对基本类型还要装箱/拆箱）；
- 更重要的是：ArrayList 内部数组可能比实际元素多预留空间（扩容策略），造成内存浪费，间接影响缓存局部性。
再对比 LinkedList：
- 访问第 i 个元素必须从头或尾逐个跳转节点，时间复杂度 O(n)；
- 每个 Node 对象有额外对象头、prev/next 引用等开销，内存不连续，CPU 缓存命中率低。
实战建议：让数组访问真正“零开销”
-
循环中避免重复读 length：写
for (int i = 0; i 时，JVM 通常能自动将 <code>arr.length提取为循环不变量，但明确写成final int len = arr.length更稳妥，尤其在老版本 JVM 或复杂嵌套场景下； - 优先用普通 for，慎用 for-each：for-each 底层仍是索引访问，但多了 Iterator 创建和 hasNext/check 等逻辑，对原始类型数组无必要；
- 批量操作尽量顺序访问：CPU 预取器对连续地址访问友好，顺序遍历比随机跳转快得多；
- 小数组优先栈上分配？不行！：Java 不支持真正的栈分配数组（逃逸分析可能优化为标量替换，但不可控），所有数组都在堆上，设计时应以复用和池化代替频繁新建。
