Java整型溢出是设计行为而非bug，因采用二进制补码表示，int溢出后绕回负数；应识别高风险场景，合理选用long、BigInteger或BigDecimal，并结合Exact方法与静态检查主动防护。
Java整型溢出不是bug，是设计行为——它不会报错，但会悄无声息地“绕回”负数。关键不是避免所有溢出，而是提前识别高风险场景，并在必要时升级数据类型或引入防护机制。
为什么 int 溢出会变负数？
Java用二进制补码表示有符号整数，int占32位，最高位是符号位。当值超过 2,147,483,647（即 Integer.MAX_VALUE）时，二进制表示从 0111...111 变成 1000...000，系统直接将其解释为负数（-2,147,483,648）。这不是异常，而是底层硬件和JVM共同定义的确定性行为。
- 例如：
int x = Integer.MAX_VALUE; x++;→ 结果为 -2147483648 - 指数增长最危险：3²⁰ ≈ 34.8亿，已远超 int 上限，第20次乘法就大概率溢出
- 累加大量小数值也可能越界，比如统计千万级订单金额总和
long 能解决哪些溢出问题？
long 是64位有符号整数，范围约 ±9.2×10¹⁸，比 int 宽阔约20亿倍。它适用于：
- 指数级增长计算：如幂运算、递推序列（斐波那契第100项）、分形迭代
-
时间戳与毫秒计数：
System.currentTimeMillis()返回 long，避免2038年问题 - 文件/内存大小计量：GB级以上容量（1GB = 1,073,741,824 字节，int 已不够）
- ID生成与计数器：Snowflake ID、数据库自增主键（尤其分库分表后）
只需把变量声明改为 long x = 1;，循环中保持 x = 3L * x;（加L后缀防隐式int运算），就能让3³⁰（≈2×10¹⁴）安全落地。
立即学习“Java免费学习笔记（深入）”；
long 也不是万能的：它也会溢出
当数值逼近 ±9,223,372,036,854,775,807 时，long 同样会绕回。典型场景包括：
- 金融系统累计交易额（百亿用户 × 千元均单）
- 天文或物理模拟中的大尺度数值累积
- 哈希累加、布隆过滤器位图索引等算法中间值
此时不能硬扛，应改用 java.math.BigInteger 或 BigDecimal（后者适合带精度要求的货币计算）。例如：
BigInteger total = BigInteger.ZERO;
for (long amount : amounts) {
total = total.add(BigInteger.valueOf(amount));
}更稳妥的做法：主动检测 + 类型选择
靠经验预估不够可靠，建议结合运行时检查：
- 使用
Math.addExact()、Math.multiplyExact()等方法——溢出时抛ArithmeticException，便于定位问题 - 对关键业务路径（如支付、库存扣减）做范围校验：
if (value > Long.MAX_VALUE - delta) { throw new OverflowException(); } - IDE或静态分析工具（如ErrorProne）可自动标记潜在溢出点
- 单元测试覆盖边界值：用
Integer.MAX_VALUE、Long.MAX_VALUE做输入验证
