math.addexact通过cpu级符号位异或与掩码运算在加法执行中实时检测溢出，编译后常内联为jo指令，零开销且异常信息明确为"integer overflow"。
Math.addExact 触发 ArithmeticException 不是靠事后校验结果，而是加法执行前或执行中就完成溢出判定——它用的是 CPU 级的符号位逻辑检测，不是“先算再比”。
溢出判断的本质：符号位异或与掩码运算
以 int addExact 为例，核心逻辑是：
- 先执行普通加法得到临时结果 r = x + y（底层仍是原生指令）
- 再用 (x ^ r) & (y ^ r)
- 这个表达式成立，说明 x 和 y 同号、但 r 符号翻转了——正+正得负 或 负+负得正，就是溢出铁证
它不依赖 Integer.MAX_VALUE 或 MIN_VALUE 常量做减法比较，因此没有边界漏判风险，也不受 0、负数、临界值等特殊情况干扰。
为什么抛 ArithmeticException 而不是其他异常
ArithmeticException 是 RuntimeException 的子类，专为“算术条件不满足”设计。Java 明确将整数溢出归类为算术错误，而非格式错误（NumberFormatException）或空指针（NullPointerException）。这带来两个实际好处：
- 调用方可用统一的 catch(ArithmeticException) 拦截所有 Exact 方法的越界行为
- IDE 和静态分析工具能识别该异常为“可预期但必须处理”的分支，强制你在编译期考虑失败路径
和手动检查、long 中转的根本区别
手写 if (a > 0 && b > 0 && a > Integer.MAX_VALUE - b) 看似直观，但实际有三处硬伤：
- 只覆盖正数相加，漏掉负数溢出（如 Integer.MIN_VALUE - 1）
- Integer.MAX_VALUE - b 可能自身就溢出（b 为负时）
- 多一次减法运算，且无法被 JIT 优化成单条 CPU 指令
而 Math.addExact 编译后常被 HotSpot 内联为带 jo（jump on overflow）的汇编指令，在 x86 平台几乎零额外开销。
异常信息自带上下文，利于定位
抛出的 ArithmeticException 消息固定为 "integer overflow" 或 "long overflow"，不带模糊描述。例如：
java.lang.ArithmeticException: integer overflow日志里一搜 "overflow" 就能命中，不需要解析堆栈或猜参数值。这对批量数据处理、定时任务、微服务间数值传递等场景特别关键——错误不会悄悄污染下游，也不会在几小时后才暴露为诡异负数。
