Java 调用 getter 出现数组越界？先看清这 3 个坑再动手

能，而且数组越界几乎都出在「getter 返回了可变数组」或「调用前没确认对象非空」这两类情况，不是 getter 语法本身的问题。最常见的三种是：getter 直接把内部数组的引用交出去、遍历时下标算错、以及对象为 null 还去调 getter。它们的适用边界很清楚：数组和对象都是引用类型，getter 一旦把内部引用暴露出去，外面改了里面也跟着变。下面把成因、复现代码和修复办法一次讲清，先把「为什么看着没越界却抛异常」这件事说透。（以上判断依据 Java 官方语言规范与异常文档。）

先看结论

选哪条先查，取决于异常栈指向的是 getter 内部还是调用方。

要系统理解 Java 的引用与数组边界，可以先过一遍 Java 教程，把值类型与引用类型的差别吃透，再看下面的反例会更顺。

一、getter 返回了别人能改的数组

最常见也最隐蔽的坑：getter 直接 return this.items;，把内部数组的引用交出去，外面一改，对象内部状态就乱了，后续再读就可能数组越界。

// 反例：返回内部数组引用（不要照抄）
public int[] getItems() {
    return this.items; // 调用方拿到引用，可越界写入
}

在本地运行这段错误代码时，调用方可以写 obj.getItems()[99] = 1，即使 items 只有 5 个元素也不报编译错，运行时才炸。修复办法是返回副本：

public int[] getItems() {
    return this.items.clone(); // 只给副本，外部改不动内部
}

失败时（比如仍抛 ArrayIndexOutOfBoundsException），先检查是不是别处改了数组长度，再修复：统一用 clone 或 Arrays.copyOf 返回防御性副本。这一条是数组越界里最高频的诱因，因为它把内部状态暴露到了对象边界之外，调用方一个越界写入就污染了整个对象。数组 API 的细节随时可查 Java 速查手册。防御性副本还能顺带解决并发问题：如果多个线程共享这个对象，外部拿到引用后修改，内部状态会悄悄串味；返回 clone 后各改各的，互不影响。这也是为什么返回数组副本几乎是 Java Bean 的默认写法。还有一种变体是把 List 直接返回，外部 get(99) 会抛 IndexOutOfBoundsException——和数组越界同源，本质都是「把内部集合暴露出去 + 外部越界访问」，用 List.copyOf 返回不可变视图同样能隔离。

二、getter 内部遍历越界

有些 getter 会在内部做转换，比如把数组拼成字符串，循环上界写错了就会越界。

public String getSummary() {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i <= items.length; i++) { // 多写了 = 号
        sb.append(items[i]).append(",");
    }
    return sb.toString();
}

这里的边界错误在于 i <= items.length，合法下标最大是 length - 1。验证时把循环条件改成 i < items.length，重新运行确认不再抛异常。数组越界在遍历场景里特别常见，根因几乎都是「上界写成了 <= 而不是 <」，要么是把长度当成了最大下标，要么是从别的语言（如 Lua，下标从 1 开始）搬过来的习惯没改过来。更稳的写法是用增强 for 循环（for (int x : items)），让编译器管边界，根本不给越界留机会；只有需要下标做额外计算时才手写索引循环，并且把上界统一用 items.length 而不是某个魔法数字。

三、对象为 null 时调 getter

如果持有对象的字段本身是 null，直接 obj.getItems()[0] 会先抛 NullPointerException，而不是数组越界——很多人因此判错方向。

if (obj != null && obj.getItems() != null && obj.getItems().length > 0) {
    int first = obj.getItems()[0]; // 先确认非空再取下标
}

这一步的判据是：凡是取下标前，都先检查对象和数组非空、长度足够。从性能取舍看，提前判空比事后捕获异常更省资源，也更好定位。注意这里的异常类型是 NullPointerException，和数组越界是两个不同的坑，别混为一谈——先看异常类名，再决定往「对象是否为 null」还是「下标是否超界」方向查。实际项目里更推荐用 Optional 显式表达「可能为空」，调用方必须处理空分支，比偷偷判空更难漏；尤其在 a.getB().getC()[0] 这种 getter 链里，任何一环为 null 都会炸，逐环判空才稳妥。

四、集合与数组混用导致下标错位

当数据在 List 和数组之间来回转，size 与 length 不一致时，用 List 的下标去读数组就会错位越界。

List<String> list = Arrays.asList("a", "b");
String[] arr = list.toArray(new String[0]);
// 用 list.size() 当数组上界是错的
for (int i = 0; i < list.size(); i++) {
    System.out.println(arr[i]); // 数量一致时才安全
}

排错时先打印 arr.length 和 list.size() 是否相等，再修复：统一用同一份数据的长度做循环上界。这类数组越界最容易被忽略，因为代码看起来「两边都是同一个 list」，但 toArray 之后手里已经是数组，循环上界必须跟着数组走。集合转数组、以及和 JavaScript 数组边界对照理解，可参考 JavaScript 教程。如果一定要用下标遍历转换后的数组，优先用 arr.length 而不是原来的集合 size()，并在转换后立即把长度缓存到局部变量，避免循环体内反复调用 size() 带来的不一致——万一循环过程中集合被别的线程改动，上界就漂了。

总结

• getter 越界大多源于「返回了可变引用」或「调用前未判空」，不是语法错。
• 返回数组时给副本（clone / Arrays.copyOf），别把内部引用交出去。
• 循环上界用 < length，别写成 <= length。
• 取下标前先确认对象与数组非空、长度足够。
• 集合与数组混用时，统一以实际读取容器的长度做上界，避免错位。
• 异常类型能反推根因：NullPointerException 是空对象，ArrayIndexOutOfBoundsException 是下标超界。
• 排查时先读异常栈顶部的类名，再决定往「空对象」还是「下标超界」方向修。

常见问题

Q：为什么 getter 返回数组后，外面改了里面也跟着变？

因为数组是引用类型，getter 直接 return 内部数组时交出去的是引用，不是副本。调用方拿到的和对象内部是同一个数组，它一改，对象状态就乱了。返回 clone 或 Arrays.copyOf 的副本即可隔离。

Q：同样是取下标，为什么有时是空指针、有时是越界？

顺序问题：如果对象或数组本身是 null，调 getter 会先抛 NullPointerException；只有对象非空、数组也非空，但下标超出 length-1 时，才抛 ArrayIndexOutOfBoundsException。看异常类型能反推卡在哪一步。

Q：循环里怎么写才不容易越界？

统一用 i < 容器.length（或 size()），别用 <=；遍历前确认容器非空；集合转数组后，循环上界用数组自己的 length，而不是原来 List 的 size。

延伸学习

• Java 架构师课程：把 Java 引用、数组与异常体系一次补齐。
• void(0) 怎么解决：另一个「调用即报错」的典型，对照着看更容易建立排查直觉。
• Javascript 开发资源：顺手把 JavaScript 的数组边界对照着学。