NegativeArraySizeException是内存分配失控的明确信号，需通过强校验长度、防整数溢出、初始化断言及熔断可观测四步前置拦截，而非捕获处理。
Java中NegativeArraySizeException在海量数据缓存场景下，不是偶然异常，而是内存分配失控的明确信号——它往往暴露的是缓存长度计算链路中的校验缺失、整数溢出或协议误读。真正有效的防范，不靠捕获，而靠前置拦截。
缓存长度来源必须强校验：尤其警惕网络响应与分页计算
海量缓存常依赖外部输入确定缓冲区大小，例如：
- HTTP响应头
Content-Length返回-1（表示长度未知），直接用于new byte[length]必炸； - 自定义二进制协议包头中解析的
payloadLen字段，若未指定字节序或符号位（如把无符号int当作有符号读），高位为1时会转成负数； - 分页缓存中计算
Math.min(pageSize, totalCount - offset)，当offset > totalCount时结果为负。
应对方式：所有长度变量在参与new前，必须显式判断>= 0，且不能仅用Math.max(0, len)静默兜底——这会掩盖越界逻辑。推荐写法：
int len = parsePacketLength(rawHeader);
if (len < 0) {
throw new IOException("Invalid payload length in cache packet: " + len + ", raw bytes: " + Hex.encodeHexString(rawHeader));
}
byte[] buffer = new byte[len];
防整数溢出：关键计算升为long，再做范围裁剪
海量数据场景下，多个缓存段长度相加（如header + body + checksum）、或大偏移量乘法（如pageSize * pageNumber）极易触发int溢出回绕成负值。Java默认不报溢出，但后续传给new就立刻抛NegativeArraySizeException。
立即学习“Java免费学习笔记（深入）”；
正确做法是：所有中间计算优先使用long，并主动检查是否超出Integer.MAX_VALUE：
long total = (long) headerLen + bodyLen + checksumLen;
if (total < 0 || total > Integer.MAX_VALUE) {
throw new IllegalArgumentException("Cache segment too large: " + total + " bytes");
}
byte[] segment = new byte[(int) total];
也可用Math.addExact/Math.multiplyExact替代常规运算，它们会在溢出时抛ArithmeticException，比负长度更早暴露问题。
缓存初始化阶段统一断言：避免框架底层误传
在MyBatis批量缓存、Redis客户端序列化、或Guava Cache加载器中，NegativeArraySizeException常是上游参数污染的结果。例如：
- 空集合传入
<foreach>导致内部缓冲区大小误算为负； - JSON反序列化失败，长度字段缺失后取默认值
-1； - 缓存key计算中哈希碰撞处理不当，引发索引错位和负偏移。
建议在缓存入口方法（如load()、computeIfAbsent()回调）最开始就对关键数值参数做断言：
public byte[] load(String key) {
int size = config.getBufferSize(key);
if (size < 0) {
log.warn("Buffer size invalid for key {}, using default", key);
size = DEFAULT_BUFFER_SIZE;
}
// 后续才进入实际缓存构造逻辑
}
生产环境需熔断+可观测：让非法长度可追踪、可降级
面对恶意构造报文或故障服务端，单次校验不够。应建立防御纵深：
- 记录原始长度值、来源字段名、请求ID、线程堆栈，便于快速区分是业务bug还是攻击行为；
- 配置连续N次收到非法
length（如5分钟内10次），自动切换至安全模式：限制最大申请1MB、改用流式读取、或拒绝该类请求； - 监控指标埋点：
cache.invalid_length_count、cache.overflow_rejects，接入告警系统。
一次没校验的长度，可能就是OOM或RCE的起点。真正的缓存健壮性，不在new byte[]那一行，而在它前面的数据清洗、类型防护和边界判定三步之内。
