Java数组长度不可变是JVM内存模型、性能优化、类型安全与并发安全共同决定的硬性约束，其连续内存布局、下标计算公式、GC识别、JIT优化、对象语义一致性及安全机制均依赖length的final特性；弹性需求由ArrayList等集合类分层实现。
Java 数组长度在创建后不可改变，不是为了限制开发者，而是由 JVM 内存模型、性能机制和安全设计共同决定的硬性约束。
内存布局要求连续且固定
数组在 JVM 堆中分配的是连续的一块内存空间，起始地址、元素类型大小、元素个数三者共同决定总占用字节数。JVM 必须在创建时就精确计算并锁定这块区域：
- 下标访问靠公式：地址 = 起始地址 + index × 单元素字节宽，若长度可变，该公式在运行时无法稳定成立
- GC 需依赖固定边界识别对象范围，动态改长会让垃圾回收器无法判断哪些内存属于该数组
- JIT 编译器会基于 length 是 final 字段做优化（如消除冗余边界检查、展开循环），改长会破坏这些优化前提
类型系统与对象语义一致性
length 是数组对象的 final 成员字段，它定义了该对象的“身份”——同一数组对象不能在不同时刻拥有不同容量：
- 编译期就能验证数组维度和访问合法性（比如 arr[5] 在 length=3 的数组上直接报错）
- equals 和 hashCode 行为依赖 length 稳定，否则同一对象多次调用结果可能不一致
- 反射、序列化、JNI 接口都把 length 当作不可变元数据使用，变动会导致跨层逻辑断裂
安全与并发模型依赖不变性
Java 的边界检查、沙箱机制和多线程场景，都隐含假设数组长度自创建起恒定：
立即学习“Java免费学习笔记（深入）”；
- 每次 arr[i] 访问前做的 if (i >= length) 检查，必须与实际内存布局严格对应；若 length 可被另一线程修改，检查与访问之间就可能出现竞态，导致越界读写
- JNI 直接传入数组指针和 length 参数给本地代码，Java 层改长而 JNI 不感知，极易引发内存踩踏或崩溃
- 模块系统和安全管理器依据数组长度做资源配额或策略判定，变动会绕过安全控制
弹性需求由更高层抽象承担
Java 并未拒绝变长能力，而是将“增长/收缩/插入”等操作明确交给引用类型集合类来分层实现：
- ArrayList 内部用数组 + size 计数器模拟逻辑可变，扩容时新建数组并复制，代价显式可控
- LinkedList、ArrayDeque 提供不同时间/空间权衡，让开发者按需选择
- 这种分工使数组专注极致随机访问性能，集合类专注灵活操作，互不干扰
