Java数组长度不可变，根本原因是其作为JVM原生类型需固定内存布局以支持O(1)访问、精确GC和JIT优化，同时保障类型安全、边界检查可靠性及JNI兼容性，变长需求由ArrayList等集合类分层承担。
Java 数组长度不可变，根本原因在于其底层直接映射 JVM 的内存模型与类型系统设计，而非语言层面的“故意限制”或“历史包袱”。它本质是固定大小的连续内存块在 Java 中的安全封装，兼顾性能、安全性和实现简洁性。
数组是 JVM 原生类型，对应固定内存布局
Java 数组（如 int[]、String[]）是 JVM 规范中定义的“第一类对象”，其 class 文件中用特殊指令（如 newarray、anewarray）创建，并在堆上分配连续、定长的内存空间。JVM 需在创建时就确定元素个数，以便：
- 计算总内存大小（头信息 + 元素区），完成精确内存分配
- 支持 O(1) 下标访问：地址 = 起始地址 + index × 单元素字节宽，无需运行时查表或跳转
- 配合 GC 精确识别对象边界，避免扫描越界或漏回收
若允许动态扩容，JVM 就需在底层支持“可重分配数组对象”，这将破坏对象内存布局的静态可判定性，大幅增加 GC 和 JIT 的复杂度。
类型系统要求编译期可验证的尺寸契约
Java 是静态类型语言，数组类型（如 int[5]）在泛型擦除后虽退化为 int[]，但其维度和长度语义仍参与编译检查（例如方法重载、反射获取 length 字段）。更重要的是：
-
length是 final 字段，JVM 保证其值自创建起恒定，使 JIT 可做长度相关的优化（如循环展开、边界检查消除） - 若允许修改长度，就等于允许改变对象“身份”——同一数组对象在不同时刻具有不同逻辑容量，破坏了对象状态一致性，也使
equals、hashCode等契约难以定义
安全模型依赖不可变结构防止越界与竞态
Java 安全机制（如沙箱、模块系统）和并发模型均隐式依赖数组长度不变性：
- 数组访问始终伴随隐式边界检查（
ArrayIndexOutOfBoundsException），该检查基于创建时确定的length值；若长度可变，检查逻辑需在每次访问前重新读取并验证，开销剧增且易引发竞态（多线程下 length 被修改导致检查与实际访问错位） - 原生 JNI 接口直接暴露数组底层数组指针和长度，若 Java 层可动态改长，JNI 侧无法同步感知，极易造成内存踩踏或读越界
替代方案已由更高层抽象承担扩展职责
Java 不提供可变长数组，并非拒绝弹性，而是将“增长/收缩/插入/删除”等操作明确交由引用类型集合类处理：
-
ArrayList内部用数组 +size计数器模拟逻辑可变，扩容时新建数组并复制，把“变长”代价显式化、可控化 -
LinkedList、ArrayDeque等按需选择不同时间/空间权衡策略 - 开发者能清晰区分：需要极致随机访问性能 → 用数组；需要频繁增删 → 用集合；无需混淆语义
这种分层让核心语言保持轻量，又不失表达力。
不复杂但容易忽略：数组长度不可变不是缺陷，而是对“内存、类型、安全、抽象”四者平衡后的必然选择。理解这一点，就能自然接受为什么 Arrays.copyOf() 返回新数组，而不是试图去“扩容原数组”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
