如何防范在数值累加过程中由于超过 long 最大值导致的负数溢出-java教程-PHP中文网

long累加变负是因二进制回绕，非计算错误；应通过math.addexact拦截溢出、biginteger彻底规避或预检范围三者组合防御。

如何防范在数值累加过程中由于超过 long 最大值导致的负数溢出

直接结论：用 long 累加大数时出现负数，不是“算错了”，而是二进制回绕——Long.MAX_VALUE + 1 必然变成 Long.MIN_VALUE。必须在溢出发生前拦截或规避。

为什么 `long` 累加会突然变负？

Java 的 long 是有符号 64 位整数，范围是 -2^63 到 2^63 - 1（即约 ±9.2×10¹⁸）。一旦累加结果超过 Long.MAX_VALUE（9223372036854775807L），就会从最大正数“翻转”为最小负数（-9223372036854775808L），后续继续加，数值就一路往上升（负得越来越少），但逻辑上已完全失真。

常见诱因包括：

统计千万级订单金额（单位为分），总和轻易突破 10^12 元 → 10^14 分，接近 long 上限
时间戳毫秒累加、计数器无重置、矩阵行列求和等未做类型预估的场景
用 Stream.reduce(0L, Long::sum) 处理超大集合，中间结果不检查

用 `Math.addExact()` 主动捕获溢出

这是最轻量、最明确的防御方式：不靠猜测，而靠运行时断言。一旦溢出，立刻抛 ArithmeticException，避免错误值污染下游。

关键点：

Math.addExact(a, b) 对任意两个 long 做加法，溢出即抛异常，不静默回绕
适合控制流清晰、能处理异常的场景（如批处理任务中止并告警）
性能开销极小（JIT 通常内联为带溢出标志的 CPU 指令）

示例：

long sum = 0L;
for (long x : values) {
    try {
        sum = Math.addExact(sum, x);
    } catch (ArithmeticException e) {
        throw new IllegalStateException("累加溢出，当前 sum=" + sum + ", 尝试加 " + x, e);
    }
}

改用 `BigInteger` 彻底消除上限

当业务逻辑**不能容忍任何中断**（如金融核心账务、审计溯源），且数据规模不可控时，BigInteger 是唯一零假设方案。

注意实际约束：

BigInteger 是不可变对象，每次加法都新建实例 → 内存占用和 GC 压力明显上升
不支持原生算术运算符（必须写 a.add(b)），代码略 verbose
若最终要落库或传给其他系统，仍需考虑是否能转成 long 或字符串

示例：

BigInteger sum = BigInteger.ZERO;
for (long x : values) {
    sum = sum.add(BigInteger.valueOf(x));
}
// 后续可安全调用 sum.longValueExact()（仅当确定没超 long 范围时）或 toString()

提前做范围预检，避免走到加法那步

对已知数据分布的场景（如日志行数、固定单价商品数量），可在循环外预判总和上限，直接拒绝或分流处理。

例如：

若每个元素 ≤ 10_000L，共 n 个，则最大可能和为 10_000L * n
检查 n > Long.MAX_VALUE / 10_000 → 若成立，说明哪怕全是最小正数也会溢出，应提前走 BigInteger 分支
比逐个调用 addExact 更快，但要求你对输入有基本约束认知

这个判断本身也要防溢出：Long.MAX_VALUE / bound 是安全的，但 bound * n 绝对不能直接算。

真正容易被忽略的是：**溢出检测不是“加完再看”，而是“加之前就该知道会不会爆”**。选 addExact 还是 BigInteger，取决于你能否接受异常中断；而预检，则取决于你有没有能力对输入规模建模。三者不是互斥，常组合使用——比如先预检粗筛，再用 addExact 做细粒度兜底。