防止long溢出的实用技巧有哪些

Java中long类型累加突然变负并非计算错误，而是64位有符号整数溢出导致的二进制回绕现象，可能引发严重逻辑失真；文章系统剖析了三大防御策略：用Math.addExact在溢出时立即抛异常实现轻量精准拦截、以BigInteger彻底消除数值上限保障金融级可靠性、通过数学预检在加法前主动规避风险，并强调三者常需组合使用——预检做粗筛、addExact作兜底，真正把防御关口前移至“加之前就该知道会不会爆”，为高可靠系统提供务实、分层、可落地的防溢出实践指南。

直接结论：用 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 做细粒度兜底。

以上就是《防止long溢出的实用技巧有哪些》的详细内容，更多关于的资料请关注golang学习网公众号！