ArrayIndexOutOfBoundsException是JVM在运行时直接比较数组长度与下标触发的异常，发生在arr[i]等访问操作处，不依赖库或泛型，仅依据数组对象头中的length字段。
ArrayIndexOutOfBoundsException抛出时，JVM到底在检查什么
这个异常不是编译期报错，而是运行时由JVM对array.length和访问下标做硬性比较后触发的。只要下标 i 或 <code>i >= array.length，JVM就立刻中断执行——不依赖任何库、不走任何代理、不看泛型擦除后的类型，纯靠数组对象头里的长度字段。
所以它永远发生在数组读写操作那一行，比如arr[i]、arr[i] = x，或System.arraycopy这类底层拷贝调用里。不会出现在ArrayList.get(i)这种封装方法里（那里抛的是IndexOutOfBoundsException，虽然继承关系相同，但源头不同）。
常见触发场景和对应排查动作
别急着加try-catch，先盯住这几类高频写法：
- 循环边界写成
i 而不是<code>i ——尤其在从其他语言转过来或手敲时容易漏掉等号 - 用
for (int i : indices)遍历索引集合，但没校验indices里每个值是否落在[0, arr.length)范围内 - 字符串切片误用
substring(start, end)，把end当成“长度”传，结果end > str.length() - 多线程环境下，一个线程刚
new int[10]，另一个线程立刻用arr[9]读——此时没问题；但如果第一个线程还没完成初始化（比如构造函数里有耗时逻辑），第二个线程可能拿到未完全初始化的数组引用（极端但真实）
怎么快速定位是哪次访问越界
堆栈信息里最顶那行就是罪魁祸首，但要注意：JVM只报“访问时”的位置，不报“谁设的下标”。比如你写了arr[computeIndex()]，异常堆栈显示的是arr[...]这一行，但真正出问题的是computeIndex()返回了负数或超长值。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
实操建议：
- 在疑似出问题的数组访问前加一行日志：
System.out.println("accessing index " + i + ", array length: " + arr.length); - 用IDE调试时，在数组访问行打条件断点，条件填
i = arr.length - 如果用的是Java 8+且启用了
-XX:+ShowCodeDetailsInExceptionMessages（JDK 12+默认开启），异常消息里会直接带上i和arr.length的具体值，省去手动打印
为什么Arrays.asList().toArray()容易踩坑
这个组合看似安全，实则暗藏越界风险：当你调用list.toArray(new String[0])，返回的是新数组；但若写成list.toArray(new String[5])，且list.size() > 5，JVM会创建一个更大的新数组并返回，原传入的new String[5]被丢弃。如果你后续还拿着那个new String[5]变量去访问，比如oldArr[5]，就必然越界——因为它的长度确实是5。
更隐蔽的是：某些旧代码会复用数组对象做缓存，比如private String[] buffer = new String[10];，然后反复调用list.toArray(buffer)。一旦某次list元素超过10个，buffer就不再是实际返回的数组，继续用它索引就会崩。
安全做法只有两种：
- 始终用
list.toArray(new Type[0])，让JVM分配刚好大小的数组 - 如果必须复用缓冲区，得自己判断：
if (list.size() > buffer.length) buffer = new String[list.size()]; list.toArray(buffer);
数组越界本身逻辑简单，难的是它常出现在“看起来不可能越界”的地方——比如下标来自配置文件解析、HTTP参数、JSON数组长度计算，这些外部输入一旦没做范围约束，arr[i]那一行就只是个导火索。
