addexact和multiplyexact专为检测整数溢出而设计，溢出时抛出arithmeticexception；它们仅支持int和long重载，不适用于short/byte/double，且需严格匹配参数类型，语义强调“结果合法”而非“计算成功”。
为什么 addExact 和 multiplyExact 会抛出 ArithmeticException
因为它们专为「检测整数溢出」而生，不是为了替代普通加法乘法。Java 的 + 和 * 在溢出时静默回绕（比如 Integer.MAX_VALUE + 1 变成 Integer.MIN_VALUE），而这两个方法会在溢出瞬间抛出 ArithmeticException，强制你处理边界问题。
常见错误现象：
用 addExact 替代所有加法，结果线上突然报 java.lang.ArithmeticException: integer overflow，但没做 try-catch；或者误以为它能用于 double 或 long 混合运算（实际只重载了 int 和 long 两组）。
-
addExact和multiplyExact都有int和long两个重载版本，没有short/byte/double版本 - 参数类型必须严格匹配：传
short会触发自动提升为int，但调用的是int版本；若想用long版本，至少一个操作数得是long字面量（如10L） - 性能上比普通运算略低（多一次溢出检查），但差距极小，别过早优化；关键是语义清晰——你要的不是“算出来”，而是“算出来还合法”
什么时候该用 addExact 而不是普通 +
当你正在做索引计算、分页偏移、循环计数、金额累加等**结果必须可逆且业务敏感**的场景时，静默溢出会导致逻辑错乱甚至数据损坏。比如数组下标越界前先校验长度，但下标本身由多个变量相加得出，这时用 addExact 就比手动写 if (a > Integer.MAX_VALUE - b) 更可靠。
- 典型使用场景：构建动态 SQL 的参数偏移量、分片键累加、时间戳毫秒值拼接、加密算法中的轮次计数
- 不适合场景：临时中间变量、循环里高频迭代（如 for 循环 i++）、日志拼接中的字符串索引计算（除非明确要求强校验）
- 注意：
addExact(a, b)不等于a + b的安全封装——它不返回默认值，也不降级，失败即中断，所以必须配合异常处理或提前预判
multiplyExact 的坑比 addExact 更隐蔽
乘法溢出阈值更低，也更难凭经验判断。比如 100000 * 100000 看着不大，但结果是 10^10，远超 Integer.MAX_VALUE（≈2.1×10^9），直接炸。
立即学习“Java免费学习笔记（深入）”；
- 常见错误：把数据库 count 结果（
long）和每页大小（int）相乘求总条目上限，却用了multiplyExact(int, int)，导致long值被截断后溢出 - 正确做法：确保至少一个参数是
long，调用multiplyExact(long, long)；或先转成long再算：Math.multiplyExact((long)a, (long)b) - 兼容性注意：Java 8 引入，Android API 24+ 支持；旧版 Android 或 Java 7 项目不能用
替代方案与边界情况怎么选
不是所有溢出都要用 Exact 方法拦住。有时你需要兜底行为（比如回退到 BigInteger）、或容忍一定误差（如统计近似值），那就要换思路。
- 需要容错时，用
Math.addExact+catch ArithmeticException→ 改走BigInteger分支 - 纯校验不执行运算？别用
Exact，改用Math.toIntExact（对long做窄化检查）或自己写溢出判断逻辑 - 注意
subtractExact和incrementExact同样存在，但使用频率低；别为了“统一风格”强行替换所有算术操作——只在真正关心溢出后果的地方加
最常被忽略的一点：这些方法只管二元运算，不管复合表达式。比如 addExact(a, b) + c 中，第一步没溢出，第二步普通加法仍可能溢出——Exact 不具备链式防护能力。
