Math.abs()、Math.max()/min() 对负零、NaN、无穷大有特殊行为;Math.round() 非银行家舍入,仅加0.5后取整;Math.pow()/sqrt() 处理负数直接返回NaN;Math.random() 线程不安全且精度有限,推荐ThreadLocalRandom。
负零、NaN、无穷大这些特殊值会让 Math.abs()、Math.max()、Math.min() 返回意料之外的结果。比如 Math.abs(-0.0) 返回 0.0(不是 -0.0),但 Math.abs(Double.NEGATIVE_INFINITY) 仍是 Double.POSITIVE_INFINITY;而 Math.max(1, Double.NaN) 直接返回 NaN,不会抛异常。
实际用时建议:
NaN 的数据,先用 Double.isNaN() 或 Float.isNaN() 过滤double 值取较大者且需排除 NaN 时,别直接写 Math.max(a, b),改用三元表达式:a >= b ? a : b(前提是已确认非 NaN)Math.min(Integer.MIN_VALUE, -Integer.MIN_VALUE) 会溢出成 Integer.MIN_VALUE,因为 -Integer.MIN_VALUE == Integer.MIN_VALUE
很多人误以为 Math.round(double) 遵循银行家舍入(四舍六入五成双),其实它只是简单地加 0.5 后向下取整:(long)Math.floor(a + 0.5d)。所以 Math.round(2.5) 是 3,Math.round(3.5) 是 4,没有“看前一位奇偶”的逻辑。
需要真正银行家舍入时:
BigDecimal:例如 new BigDecimal("2.5").setScale(0, RoundingMode.HALF_EVEN).intValue()
Math.round() 做金融计算,二进制浮点误差会让 2.4999999999999996 被 round 成 2,而你本意是 3
Math.round(float) 返回 int,Math.round(double) 返回 long,类型不一致容易引发隐式转换 bugMath.pow(base, exponent) 在 base 且 exponent 不是整数时返回 NaN,比如 Math.pow(-2, 0.5) 是 NaN(不是复数),Math.pow(-8, 1.0/3.0) 也返回 NaN,哪怕数学上等于 -2。
Math.sqrt(x) 对 x 一律返回 NaN,对 0.0 和 -0.0 都返回 0.0。
性能与替代方案:
Math.sqrt(x),它底层调用的是平台优化的 native 实现,比 Math.pow(x, 0.5) 快且更准Math.sqrt(n) 再转 int 比较,易因浮点误差错判;改用二分或 long root = (long) Math.sqrt(n); if (
root * root == n) {...} 并补校验Math.pow(10, n) 计算数量级时,对大 n(如 n > 308)会溢出为 Infinity,注意检查Math.random() 返回的是共享的 Random 实例,多线程高频调用会有竞争,虽不抛异常但可能降低吞吐。它只生成 [0.0, 1.0) 的 double,要生成 [a, b) 整数得手动缩放:(int)(Math.random() * (b - a) + a),但这个表达式在 b - a 很大时有精度丢失风险(double 只有 53 位有效位)。
更稳妥的做法:
ThreadLocalRandom.current().nextInt(a, b) 替代,线程安全、无锁、支持闭区间语义(nextInt(a, b) 是 [a, b))Math.random(),它无法设置 seed;必须显式 new Random(seed)
Math.random() * Integer.MAX_VALUE 可能产生超过 int 范围的值,强制转 int 会截断,应先用 nextLong() 或限定范围再 castThreadLocalRandom random = ThreadLocalRandom.current(); int dice = random.nextInt(1, 7); // [1, 7) → 1~6 long bigRand = random.nextLong(0L, 1_000_000_000_000L);
很多开发者卡在 Math 类的“看起来安全,实则藏坑”的细节上——比如用 Math.round() 处理金额、拿 Math.pow() 算负数开方、或者在并发场景下无脑调 Math.random()。这些方法本身没毛病,但 Java 的 Math 是严格按 IEEE 754 和 JDK 规范走的,不替你做业务假设。