Java数组长度上限为Integer.MAX_VALUE（2147483647），因JVM规范强制length字段为int类型且字节码指令仅支持32位操作数，超限会抛NegativeArraySizeException或OutOfMemoryError。
Java数组长度上限不是由内存大小直接决定的，而是被JVM规范硬性锁定在 Integer.MAX_VALUE（2147483647）。超过这个值，哪怕堆内存充足，也会失败——根本原因在于数组长度字段是 int 类型，字节码指令只接受32位操作数。
为什么最大只能是2147483647？
JVM规范明确定义：所有数组对象头中存储的 length 是一个32位有符号整数，对应 Java 的 int 类型。这意味着：
- 索引范围固定为 0 到 2³¹−1，无法用
long表达更大长度 - 字节码指令如
anewarray、newarray的参数宽度仅为32位，不支持 long 型长度输入 - 即使你写
new int[(int) 3_000_000_000L]，强转后溢出为负数，直接抛NegativeArraySizeException - HotSpot 等主流 JVM 还会在内部设更保守阈值，比如
Integer.MAX_VALUE - 8，预留对象头空间
为什么实际建不出这么大的数组？
理论值 ≠ 可用值。真正能成功分配的数组长度远小于此，受三重制约：
-
连续堆内存不足：例如
int[2147483647]至少需约 8.6GB 连续空间（4B × 2147483647 + 对象头 + 填充），而JVM很难在堆中找到这么大且连续的空闲块 -
JVM主动拦截：错误信息为
Requested array size exceeds VM limit，说明JVM在分配前就拒绝了，增大-Xmx无效 - 对象头与对齐开销：64位JVM启用压缩指针时对象头约12字节；禁用后达16字节，进一步挤压可用容量
不同元素类型的实际影响
单个元素占的空间越小，同堆下可容纳的元素数越多，但依然逃不开 int 长度上限：
立即学习“Java免费学习笔记（深入）”；
-
byte[]或boolean[]：每个元素1字节 → 理论最多接近 2GB 元素，但仍卡在Integer.MAX_VALUE -
int[]：每个4字节 → 同堆下长度约为 byte 数组的 1/4 -
long[]或double[]：每个8字节 → 长度再减半 -
Object[]：引用大小取决于是否启用压缩指针（通常4字节），但还要算上元素本身对象的内存占用
遇到超大需求怎么办？
当业务逻辑需要“逻辑容量”远超21亿时，必须放弃单数组模型：
- 用二维数组模拟：如
int[65536][32768]，总元素数接近上限，同时提升缓存友好性 - 分块管理：自定义
BigArray或使用ArrayList<int[]>，按需加载子数组并映射逻辑索引 - 内存映射文件：
MappedByteBuffer将数据落盘，靠虚拟内存访问TB级数据，适合只读或顺序写场景 - 下沉到外部存储：稀疏或随机访问场景优先选数据库、Redis 或专用列存引擎
