Java整数溢出解决方案及Math.addExact使用技巧

Java中整数加法溢出会静默回绕而非报错，极易引发隐蔽的业务逻辑错误；Math.addExact提供零依赖、高性能、异常明确的解决方案——溢出时立即抛出带清晰提示的ArithmeticException，强制开发者处理异常，避免掩盖问题，其底层由JVM内联优化，性能几乎与原生加法无异，是Java 8起官方推荐的首选防溢出实践，尤其适用于循环索引、分页计算、时间差等易被忽视的隐性溢出场景。

Java整数加法溢出时程序不报错，但结果错误

Java默认的 + 运算符对 int 和 long 完全不检查溢出，超范围就静默回绕（比如 Integer.MAX_VALUE + 1 得到 Integer.MIN_VALUE）。这不是bug，是JVM规范行为，但业务逻辑里往往要的是“出错即失败”，而不是“错得悄无声息”。

直接用 Math.addExact 是最轻量、零依赖的解法：它在溢出时抛出 ArithmeticException，且编译期就能被IDE识别为“可能抛异常”，强制你处理。

• Math.addExact(int, int) 和 Math.addExact(long, long) 是唯二可用的重载，不支持 short/byte，用之前得先升成 int
• 别试图包装成工具方法去“吞掉异常”——掩盖溢出比暴露它更容易引发后续数据错乱
• 注意：它只检查结果是否溢出，不检查参数本身是否非法（比如 null 不适用，因为是基本类型）

为什么不用 try-catch 包裹普通加法来检测溢出

有人想自己写逻辑判断：先算再比大小，或者用 long 中转再截断。这些方式要么冗长易错，要么引入隐性开销。而 Math.addExact 底层是HotSpot内联的汇编级检查（x86有 jo 指令），性能几乎和原生加法一致。

• 手写判断如 if (a > 0 && b > 0 && a > Integer.MAX_VALUE - b) 容易漏边界（比如 a == 0 或负数场景）
• 用 long 中转再强转回 int 并不能防止溢出——只是把溢出延迟到转型那一刻，且多一次类型转换
• Math.addExact 的异常信息明确包含 “integer overflow”，日志里一眼可定位问题点

替代方案对比：StrictMath、BigInteger、第三方库

StrictMath.addExact 行为和 Math.addExact 完全一致，但没必要用——StrictMath 是为保证跨平台浮点严格一致设计的，整数运算本就不涉及精度差异。

• BigInteger 能避免溢出，但对象创建开销大，GC压力明显，仅适合已知会长期参与复杂计算的场景，不是加两个计数器的合理选择
• Guava 的 IntMath.checkedAdd 功能等价，但多一个依赖；Apache Commons Math 的 Precision.round 等不解决整数加法溢出问题
• Java 8 引入 Math 系列 Exact 方法（add/subtract/multiply/toIntExact）就是为统一解决这类问题，别绕路

容易忽略的隐性溢出点：循环索引、时间戳差值、分页计算

溢出不一定出现在显眼的“大数相加”。比如 for (int i = start; i 中，如果 end 是 Integer.MAX_VALUE，i += step 可能直接回绕成负数，导致死循环；又比如用 System.currentTimeMillis() 差值做超时判断，两个 long 相减结果若被误存为 int，就丢精度。

• 所有涉及用户输入、配置值、外部接口返回的整数参与运算前，只要可能接近边界，就该用 Math.addExact 或对应方法
• Math.toIntExact(long) 对从数据库或JSON读出的大整数特别有用——它比强制转型更安全，且异常信息直指来源
• 注意：泛型容器（如 List）的 size() 返回 int，但某些实现（如 Arrays.asList 包装超大数组）理论上可能触发溢出，不过实际中 JVM 对数组长度有限制（2^31-1），这点倒不用过度防御

事情说清了就结束

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~