java通过jvm在字节码执行阶段强制插入数组边界检查来避免缓冲区溢出，所有数组访问指令（如iaload、bastore等）均须验证索引是否在[0, array.length)范围内，越界即抛出无法绕过的arrayindexoutofboundsexception。
Java 能避免 C 语言风格的缓冲区溢出，核心不靠“程序员自觉”，而靠 JVM 在字节码执行阶段强制插入的数组边界检查——这不是可选优化，是每个数组访问指令的硬性约束。
数组访问指令自带边界校验
JVM 规范要求，所有数组读写操作（如 iaload、bastore、aastore 等）在执行前必须验证索引值是否在 [0, array.length) 范围内。一旦越界，立即抛出 ArrayIndexOutOfBoundsException，且该异常无法被绕过或禁用。
- 例如：执行
arr[i]时，JVM 实际生成的字节码会先加载i和arr.length，再比较i >= 0 && i - 这个检查发生在运行时，由解释器或 JIT 编译器生成的本地代码中保留，即使开启激进优化（如循环展开），JVM 仍保证至少一次边界检查（通过“范围检查消除”优化时也仅在确信安全的前提下省略）
内存布局与访问隔离杜绝覆盖可能
Java 对象（包括数组）统一在堆上分配，由 JVM 全权管理内存布局。数组对象头中明确记录长度，且数据区与元信息、相邻对象严格隔离：
- 不存在“相邻栈帧被覆盖”的风险——Java 没有 C 那样的局部数组放在栈上、返回地址紧挨着缓冲区的布局
- 堆内存由 GC 管理，不暴露裸指针；没有
malloc + strcpy这类手动偏移写入的机制 - 即使发生越界，也不会导致任意内存覆写——因为越界访问根本不会执行，而是中断在检查环节
无指针算术与不可变长度保障底层安全
Java 语言层彻底移除了指针运算能力，所有数组访问只能通过合法索引进行；同时数组长度在创建后不可修改，杜绝了“动态伸缩+逻辑误判”引发的二次越界场景：
- 没有
&arr[0] + offset这类地址计算，也就没有绕过索引检查的路径 - 像
System.arraycopy这类底层复制方法，其参数（源起始、目标起始、长度）同样受 JVM 运行时检查，任一参数越界都会提前失败 - 反射访问数组（如
Array.get()）也走同一套边界校验逻辑，不构成例外通道
这套机制不是“尽力而为”的防护，而是 JVM 执行模型的基石之一——它让缓冲区溢出在 Java 中从“高危漏洞”降级为“编译期/运行期可捕获的编程错误”，从根本上切断了攻击链的起点。
