NegativeArraySizeException 表明数组长度为负，需在 new 前校验：如 assert n >= 0 或 if (n

Java 中 new int[n] 报 NegativeArraySizeException 怎么定位？

这个异常不是运行时“偶然”发生的，而是数组创建那一刻就炸了——JVM 直接拒绝分配负长度的内存。它不进 catch 块、不等逻辑执行完，只要 new 语句里尺寸是负数，立刻抛出。

常见错误现象：NegativeArraySizeException 堆栈通常只有一行，指向 new 那行，但真正的问题往往藏在计算长度的表达式里，比如 list.size() - offset 算成负数，或用户输入没校验直接当长度用。

使用场景：

• 从字符串截取子数组，endIndex - startIndex 为负
• 分页计算页内数据量：Math.min(pageSize, total - (page <em> pageSize))</em> 中 total 小于 page pageSize
• 反序列化时读到损坏的长度字段（如网络包、二进制文件）

实操建议：

• 在 new 前加一行断言：if (n
• 用 Math.max(0, n) 强制兜底虽能避免崩溃，但掩盖了逻辑缺陷——该报错的地方不能静默修正

为什么 catch NegativeArraySizeException 几乎没意义？

这不是可恢复的业务异常，而是程序逻辑错误的明确信号。JVM 不允许负长度数组存在，也没有“重试”或“降级创建”的余地。

性能 / 兼容性影响：
捕获它本身开销极小，但问题在于——你 catch 之后打算做什么？

• 返回空数组？那上游很可能因长度不对而 NPE 或越界
• 记录日志然后继续？等于放任 bug 在生产环境持续触发
• 抛出更明确的自定义异常？可以，但不如提前拦住

实操建议：

• 不要写 catch (NegativeArraySizeException e)
• 把校验前移到计算环节，例如：

  int len = computeLength();
  if (len < 0) {
    throw new IllegalStateException("invalid length computed: " + len);
  }
  byte[] buf = new byte[len]; // 这里才真正创建
  

哪些常见函数/操作容易间接导致 NegativeArraySizeException？

很多看似安全的工具方法，底层仍是 new 数组，一旦传入负数就会引爆。

常见错误点：

• Arrays.copyOf(arr, newLength)：当 newLength 为负时直接抛
• String.substring(begin, end)：如果 begin > end，内部 new char[] 时长度为负
• ByteBuffer.allocate(n)：n IllegalArgumentException）
• Jackson / Gson 反序列化集合字段时，若 JSON 中数组长度字段为负数（极少见但可能由恶意或损坏数据引起），某些老版本解析器会透出此异常

参数差异提醒：

• ArrayList.ensureCapacity(minCapacity) 不会抛这个异常，它只扩容，不创建新数组
• 但 ArrayList.toArray(new String[size]) 会——size 是你传的，负数照炸

测试时怎么主动触发并验证修复是否到位？

别等线上崩了才发现。写单元测试时，必须显式覆盖边界外输入。

实操建议：

• 对每个接受“长度”参数的方法，加一个 @Test 用负数调用
• 检查是否在创建数组前就拦截，而不是靠 JVM 抛异常来兜底
• 示例（JUnit 5）：

  @Test
  void shouldFailFastOnNegativeLength() {
    assertThatThrownBy(() -> processWithLength(-1))
        .isInstanceOf(IllegalArgumentException.class)
        .hasMessageContaining("length");
  }
  

容易被忽略的一点：IDE 的自动补全或 Lombok 的 @Builder 可能悄悄把未校验的 int 字段塞进数组创建逻辑里。只要长度来源没经过 assert / if 检查，就始终有风险。