Math.abs对Integer.MIN_VALUE返回原值而非绝对值，因其超出int范围；应转long处理或用floorMod等安全方法。
Java里用Math.abs取整数绝对值，基本没问题但要注意溢出
Math.abs对int和long类型都提供重载，日常用起来很顺手。但它对Integer.MIN_VALUE（即-2147483648）这种边界值不返回正数，而是原样返回负数——因为它的绝对值超出了int能表示的范围。
- 常见错误现象：
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE结果为true，不是2147483648 - 本质原因：
int是32位补码，-2147483648的按位取反加1会溢出回自身 - 如果你真需要这个值的“数学上”的绝对值，得先转成
long：Math.abs((long) Integer.MIN_VALUE) - 性能影响几乎为零，JVM对
Math.abs有intrinsics优化，编译后常直接映射为CPU指令
Math.abs在字节码和JVM层面到底干了啥
它不是纯Java实现的普通方法，而是被HotSpot JVM特殊处理的intrinsic函数。对int参数，最终通常编译为一条mov eax, edx; neg eax; cmovl eax, edx这类条件取负指令（x86-64），不走分支预测，也不调用任何Java栈帧。
- 你反编译
Math.abs(123)看不到方法调用，而是一个紧凑的寄存器操作序列 - 但
Math.abs(Integer.MIN_VALUE)不会触发异常，也不会做额外检查——JVM信任你清楚补码规则 - 注意：这个优化只对
int/long/float/double有效；short或byte传入会先提升为int再进abs
什么时候不该用Math.abs，而该自己写逻辑
当你的业务语义上不能容忍Integer.MIN_VALUE被“忽略”时，比如做索引计算、数组长度校验、哈希桶定位等，直接套Math.abs可能埋下越界隐患。
- 典型场景：用
Math.abs(x.hashCode()) % array.length做哈希映射——若x.hashCode() == Integer.MIN_VALUE，结果仍是负数，导致ArrayIndexOutOfBoundsException - 安全写法：
(x.hashCode() & 0x7fffffff) % array.length（适用于非负掩码场景） - 更通用方案：先转
long再取模，或用Math.floorMod(x.hashCode(), array.length)（JDK 8+，自动处理负数） - 别用
Math.abs(x) 来判断是否溢出——它永远是<code>false，没意义
为什么Math.abs不抛异常也不返回Optional
因为它是JDK底层基础工具，设计目标是零开销、确定性、与C标准库行为一致。Java从1.0就定死了这个语义，改不了，也不能加运行时检查。
立即学习“Java免费学习笔记（深入）”；
- 兼容性优先：已有海量代码依赖
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE这一事实 - 泛型擦除限制：无法为
int提供返回Optional<integer></integer>的重载 - 真正关键的逻辑里，你应该自己控制输入范围，而不是指望
abs兜底 - 如果项目允许JDK 17+，可考虑用
Math.toIntExact(Math.abs((long) x))捕获溢出，但注意这会抛ArithmeticException
Math.abs就万事大吉”的事，尤其当你在写容器、序列化、数值计算这类底层逻辑时，Integer.MIN_VALUE那个看似安静的负数，往往会在最意想不到的地方翻车。 
