math.round(-1.5) 返回 -1，因其等价于 floor(-1.5 + 0.5) = floor(-1.0) = -1，而非传统四舍五入；math.random() 生成 [a, b) 整数应写为 (int)(math.random() * (b - a)) + a，右边界不可达。
Math.round() 为什么 -1.5 四舍五入得 -1 而不是 -2
Java 的 Math.round() 不是传统数学四舍五入，而是「向正无穷方向偏移 0.5 后取 floor」。等价于 (long)Math.floor(a + 0.5d)，负数时这个逻辑会“抬高”数值，导致 -1.5 → -1.0 → floor 得 -1。
- 常见错误现象：
Math.round(-1.5)返回-1，误以为是 bug 或平台差异 - 使用场景：需要真正四舍五入（如财务计算）时，不能直接用
Math.round() - 实操建议：对负数做修正——
(long)Math.floor(x + (x >= 0 ? 0.5 : -0.5))；或统一转为BigDecimal配合RoundingMode.HALF_UP - 性能影响：自定义四舍五入比原生
Math.round()多一次条件判断和加法，但无明显瓶颈；除非高频调用（如每秒百万级），否则不必优化
Math.random() 生成 [a, b) 区间整数的正确写法
直接用 (int)(Math.random() * (b - a)) + a 看似简洁，但存在两个隐性问题：类型截断丢失精度、区间右边界不可达却常被误认为闭区间。
- 常见错误现象：想生成 [1, 6]（骰子），写了
(int)(Math.random() * 6) + 1，结果永远得不到 6 —— 因为Math.random()最大值是0.999...，乘 6 后最大约 5.999...，(int)截断后仍是 5 - 使用场景：游戏逻辑、测试数据生成、简单随机抽样
- 实操建议：生成 [a, b] 整数，用
a + (int)(Math.random() * (b - a + 1))；注意括号位置，避免整数除法或提前截断 - 兼容性提醒：Java 17+ 推荐改用
ThreadLocalRandom.current().nextInt(a, b + 1)，线程安全且不依赖系统时间种子
double 类型传给 Math.abs() 可能返回 -0.0
Math.abs(-0.0) 返回 0.0，但 Math.abs(0.0) 也返回 0.0 —— 表面一样，底层 IEEE 754 符号位不同。多数场景无感，但在严格比较、序列化或浮点哈希时可能出问题。
- 常见错误现象：用
==比较Math.abs(x)和0.0时结果正确，但后续传给Double.hashCode()或 JSON 序列化后出现不一致 - 使用场景：金融计算中间值归零、图形坐标归一化、浮点键 Map 查找
- 实操建议：若需彻底消除符号位，用
Double.doubleToLongBits(x) & 0x7fffffffffffffffL再转回 double；或更稳妥地，用x == 0.0 ? 0.0 : Math.abs(x) - 性能影响：位运算方案略快于条件判断，但差异在纳秒级；日常代码优先选可读性高的条件写法
Math.pow(x, y) 在整数幂场景下不如手写乘法高效
Math.pow() 是通用双精度浮点幂函数，内部走 exp(y * log(x))，即使 x、y 都是小整数（比如 Math.pow(2, 10)），也会触发浮点运算链，还带误差风险。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：
Math.pow(10, 2) == 100.0大概率成立，但Math.pow(10, 15)可能因精度丢失变成1000000000000000.1，强制转long就溢出 - 使用场景：循环中频繁计算固定小整数幂（如 2^n、10^n）、配置解析时解析指数字段
- 实操建议：y 是已知小整数（≤20）时，直接写
x * x、x * x * x；或封装静态工具方法如pow2(int n)用位移（1 ）；避免在 hot path 里调 <code>Math.pow() - 兼容性提醒：JDK 21 的
Math.exp2()、Math.expm1()等专用函数也不适用于整数幂优化，它们解决的是另一类精度问题
最易被忽略的是 Math.round() 对负数的处理逻辑，以及 Math.random() 的右开区间本质——这两个点在线上出过不少低级但难复现的 Bug。别信直觉，查源码或写个单元测试验证边界值。
