数组越界本身不会直接导致全站假死，真正致命的是越界后引发的不可恢复状态叠加容错断层——比如静默覆盖关键内存字段、线程无限循环、上下文污染或资源锁死。
数组越界本身不会直接导致全站假死，真正致命的是越界后引发的不可恢复状态叠加容错断层——比如静默覆盖关键内存字段、线程无限循环、上下文污染或资源锁死。这类事故往往没有异常堆栈，监控显示“一切正常”，但用户端已大面积超时或白屏。
越界不抛异常，才是最危险的开始
System.arraycopy 在两类场景下会静默越界：
- length == 0 时，无论 srcPos 或 dstPos 多离谱（如负数、远超数组长度），JVM 都跳过校验，不报错也不执行
- 目标数组是堆外内存（如 DirectByteBuffer），越界写入落在可读写页内，可能只篡改邻近字段（如 capacity 被写成极大负数），后续操作陷入死循环
事故中正是后者：加解密模块用 DirectByteBuffer 做缓冲区，dstPos 计算错误，覆盖了紧邻的 capacity 字段。之后所有 put() 操作都在边界检查里无限循环，线程卡死，却无任何异常日志。
单点越界滚成全站雪崩，缺的是防御纵深
问题不在越界动作本身，而在系统缺乏分层拦截能力：
- 没有线程级超时：卡死线程持续占用 Tomcat 工作线程，不中断、不释放
- 无熔断降级：上游线程阻塞，下游服务无法及时返回，调用链路连锁拖垮
- 健康检查失效：/actuator/health 仍返回 UP，因为主线程和心跳线程未受影响，运维看到的是“假性健康”
结果是 QPS 断崖下跌、错误率显示为 0%，而用户大量遭遇 504 和白屏——典型的“无错误假死”。
容错不能靠 try-catch 堆砌，要前置到契约与校验
把 arraycopy 包一层 try-catch 不仅无效，反而有害：
- 捕不到静默越界，也救不了已被破坏的内存结构
- 高频路径加异常捕获会增加 JIT 编译压力，降低吞吐
- 掩盖了真正的校验缺失——越界本该在进入拷贝前就被拦截
有效做法是分层设防：
- 输入校验层：所有外部传入的 pos/length 参数，在进入任何数组操作前统一做 checkIndex(src, srcPos, length)
- 内存契约层：关键缓冲区（如加解密、序列化）强制使用封装类（如 SafeArrayView），构造时冻结长度与有效区间
- 运行时防护层：JVM 启动参数加入 -XX:+UseMembar -XX:+AlwaysPreTouch，减少因内存页未映射导致的隐性延迟
多线程与反射场景下，越界更隐蔽
数组在并发或框架调用中极易成为“薛定谔容器”：
- 多线程共享数组时，长度检查通过后，另一线程可能瞬间清空或重置数组
- MyBatis、JSON 反序列化等框架返回的数组，类型判断为 array 后仍可能 length == 0
- Stream 或 Lambda 中对数组引用的闭包捕获，可能在流执行时数组已被修改或销毁
安全写法包括：用 Optional.ofNullable().filter(arr -> arr.length > 0) 替代直接索引；反射调用前用 Array.getLength() 获取真实长度；避免裸用数组，优先选用 List 或封装视图。
