Java整数溢出不报错而静默回绕，如int最大值2147483647加1变为-2147483648；这是补码机制和硬件设计决定的默认行为，虽非bug但极易引发逻辑错误，需用Math.addExact等方法主动检测或升级为long/BigInteger防范。
Java整数类型溢出不会报错，而是静默回绕——数值超出范围后自动跳到另一端，比如int最大值加1变成最小值。这不是bug，是补码机制和硬件设计决定的行为，但极易引发逻辑错误。
各整数类型的取值范围与溢出起点
Java中四种有符号整型均按补码存储，溢出时统一遵循“模 2n 回绕”规则（n为位数）：
- byte（8位）：范围 -128 ~ 127；127 + 1 → -128，-128 - 1 → 127
- short（16位）：范围 -32768 ~ 32767；32767 + 1 → -32768
- int（32位）：范围 -2147483648 ~ 2147483647；2147483647 + 1 → -2147483648
- long（64位）：范围 -9223372036854775808 ~ 9223372036854775807；超限后同样回绕，只是概率更低
溢出后的数据变化不是随机的，而是可预测的截断
所有整数运算（加、减、乘）结果都会被强制截断为对应类型的位宽。例如：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
int x = Integer.MAX_VALUE; System.out.println(x * 2);输出 -2 —— 因为 2147483647 × 2 = 4294967294，二进制低32位恰好是 -2 的补码 -
int y = -1; System.out.println(y * y);输出 1（正常），但y = Integer.MIN_VALUE; System.out.println(y * y);输出 0 —— 因为 (-2147483648)² 远超 int 范围，低位32位全为0 -
IntStream.of(41,65,14,...).reduce(1, (a,b)->a*b)最终得 0，并非真为零，而是中间某步溢出后低位归零所致
为什么溢出难被发现？关键陷阱场景
溢出不抛异常、不打印警告，错误值可能潜伏数层调用之后才暴露：
立即学习“Java免费学习笔记（深入）”；
- 循环计数器从
Integer.MAX_VALUE加1后突变为负数，导致for (int i = 0; i < n; i++)变成无限循环 - 金额计算、积分累加、ID生成出现负数或零，后续校验直接失败
-
arraySign()类方法依赖乘积符号判断正负，但溢出变0后误判为“无符号” - 调试时变量显示 -2147483648，看起来“合理”，实则是回绕假值，掩盖真实计算崩溃点
实战中推荐的应对策略
不靠运气，靠机制：
- 对关键业务计算（如金融、计费、ID生成），优先使用
Math.addExact()、Math.multiplyExact()等方法——溢出时明确抛ArithmeticException，让问题在源头暴露 - 预估结果可能超 int（比如累加万级用户行为、时间戳差值），直接声明为
long；若上限完全不可控（如大数阶乘、密码学运算），用BigInteger - 简单逻辑可手动边界检查，例如加法前判断：
if (a > 0 && b > Integer.MAX_VALUE - a)，但需注意符号组合和整除误差，慎用于乘法 - 静态分析工具（如ErrorProne）或IDE警告（如IntelliJ的“Possible overflow”提示）应开启并重视
