Java一维数组性能优势源于JVM保证的连续内存布局，支持O(1)随机访问；栈中仅存引用，堆中整块连续存储，使寻址只需一次加法运算，且GC、异常检测均由此确定性支撑。
Java 一维数组的性能优势，根源不在语法糖或工具类，而在于它在内存中实实在在的连续布局——这是 JVM 层面硬性保证的物理事实，直接决定了它的访问效率天花板。
连续内存是 O(1) 查找的唯一前提
声明 int[] arr = new int[1000]; 时，JVM 必须在堆中一次性申请一块 4000 字节（1000 × 4）的连续空间。首元素地址即为数组对象起始地址，第 i 个元素地址 = 首地址 + i × 4。CPU 不需要遍历、不依赖哈希、不查链表，只做一次加法运算就能定位——这就是随机访问稳定在常数时间的全部原因。
- 哪怕数组长度从 10 增到 100 万，
arr[500000]的访问耗时几乎不变 - 非连续结构（如 LinkedList）无法复现这种数学寻址能力
- 即使现代 CPU 的缓存预取优化，也是建立在“连续”这一前提之上才有效
栈与堆分工明确，避免运行时歧义
变量名（如 arr）只是栈中的一个 4 或 8 字节引用，真正数据全在堆里。这种分离带来两个关键确定性：
- 栈上操作极快：赋值
int[] b = arr;只复制地址，无数据拷贝开销 - 堆上布局可控：JVM 知道整个数组占多少字节、边界在哪，GC 回收时能精准识别整块内存
- 空指针异常（NPE）和越界异常（ArrayIndexOutOfBoundsException）都能在最靠近硬件的层级被快速捕获
现代 Java 工具类是在这个底层上“锦上添花”，而非改变本质
Arrays.copyOf、Arrays.fill、Arrays.setAll 这些方法之所以高效，是因为它们内部仍基于连续内存做批量操作——比如 fill 直接用内存块填充指令（如 x86 的 rep stosd），比手动 for 循环快一个数量级。
立即学习“Java免费学习笔记（深入）”；
-
Arrays.stream(arr)会触发装箱，但IntStream.range(0, arr.length).map(i -> arr[i])可绕过对象创建，保持原始类型路径 - 频繁修改长度？不是数组的问题，而是选型问题——该用 ArrayList 就别硬套数组
- 大数组初始化慎用
{1,2,3,...}字面量，编译器会展开成冗长字节码；改用new int[n]+Arrays.setAll更干净
性能边界清晰：快在哪，慢在哪，一目了然
数组快，只快在“按位置拿”；慢，也只慢在“按内容找”或“中间插删”。这不是缺陷，而是设计契约。
- 查找指定值？必须遍历 → O(n)，用
Arrays.binarySearch前得先排序 - 在索引 5 处插入一个数？后面 995 个元素全得挪位 → O(n)
- 但末尾追加？只要容量够，就是纯写内存 → O(1)
- 多线程安全？数组本身无锁，需靠
VarHandle或外部同步保障
