java数组长度不可变是jvm内存模型与运行时安全机制决定的底层约束，length为public final int字段，创建后固化，内存布局要求连续定长空间，边界检查依赖其绝对稳定。
Java数组长度不可变，不是语法限制，而是由JVM内存模型与运行时安全机制共同决定的底层约束。它直接绑定在数组对象的生命周期起点，一旦创建完成，length就固化为final字段，无法被任何代码路径修改。
内存布局决定了长度必须固定
数组在堆中分配的是连续、定长的内存块。例如 int[] arr = new int[5]，JVM立即划出 5 × 4 = 20 字节的连续空间，并记录起始地址和元素宽度。后续所有下标访问都靠“起始地址 + index × 4”快速计算——这个公式成立的前提，就是长度和单元素大小从不变化。
如果允许扩容，就必须：重新申请更大连续内存 → 复制全部旧数据 → 修改引用指向 → 释放旧空间。这已超出数组的职责范畴，属于ArrayList等集合类要处理的逻辑。
length是final字段，编译期即锁定
arr.length 是 public final int 类型，JVM保证其值自对象创建后恒定不变。这意味着：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- arr.length = 10; → 编译报错：不能为final字段赋值
- 反射强行修改 length 字段 → 运行时抛出 IllegalAccessException 或被JVM静默忽略
- 没有 resize()、add()、setLength() 等方法 —— 这些根本不存在于数组API中
边界检查依赖长度的绝对稳定性
每次通过 arr[i] 访问元素时，JVM都会插入隐式边界检查：if (i = arr.length) throw ArrayIndexOutOfBoundsException。这个检查必须基于一个不会被并发线程篡改的length值。
若length可变，在多线程场景下可能出现：检查时 i
替代方案不是补丁，而是分层抽象
遇到需要动态增删的场景，不应试图“绕过”数组限制，而应选择语义匹配的工具：
- 不确定最终大小、频繁增删 → 用 ArrayList
（底层自动扩容，封装了new + copy逻辑） - 仅需偶尔扩展、数据量小且追求可控性 → 手动 Arrays.copyOf(arr, newSize)
- 长度在编译期或启动时完全确定、高频随机访问 → 数组仍是最佳选择，零额外开销
数组是内存的“物理载体”，ArrayList是带管理逻辑的“智能包装器”。二者分工明确，混淆职责反而增加复杂度。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
