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 是为保证跨平台浮点严格一致设计的，整数运算本就不涉及精度差异。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
BigInteger能避免溢出，但对象创建开销大，GC压力明显，仅适合已知会长期参与复杂计算的场景，不是加两个计数器的合理选择 - Guava 的
IntMath.checkedAdd功能等价，但多一个依赖；Apache Commons Math 的Precision.round等不解决整数加法溢出问题 - Java 8 引入
Math系列Exact方法（add/subtract/multiply/toIntExact）就是为统一解决这类问题，别绕路
容易忽略的隐性溢出点：循环索引、时间戳差值、分页计算
溢出不一定出现在显眼的“大数相加”。比如 for (int i = start; i 中，如果 <code>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），这点倒不用过度防御
事情说清了就结束
