17370845950

Math类因基于IEEE 754双精度浮点数，无法精确进行小数运算，如0.1+0.2≠0.3；金融复利、随机百分比四舍五入、double相等判断等场景易出错。

Math类不能做精确小数运算

Java的Math类所有方法都基于double，本质是IEEE 754浮点数，天然存在精度丢失。比如0.1 + 0.2结果不是0.3而是0.30000000000000004，用Math.round()或Math.floor()也改不了这个底层问题。

常见踩坑场景：

• 金融计算中直接用Math.pow(1.05, 2)算复利，结果带误差
• 用Math.random() * 100生成百分比再四舍五入，边界值（如99.999999）可能进位错误
• 比较两个double是否相等时，误用==而不是Math.abs(a - b)

BigDecimal构造必须用字符串，不能用double

用new BigDecimal(0.1)看似合理，实际传入的是0.1000000000000000055511151231257827021181583404541015625——这是double字面量在内存中的真实值。正确做法永远是new BigDecimal("0.1")。

关键细节：

• BigDecimal.valueOf(double)内部做了Double.toString(d)转换，比直接构造安全，但仍有陷阱：如果d本身是计算结果（如0.1 + 0.2），toString后仍是错误值
• 所有业务中涉及金额、利率、权重等需精确小数的字段，初始化源头就必须是String或long
• 从数据库读取的DECIMAL字段，JDBC驱动通常返回BigDecimal，此时无需转换；但若用getDouble()再转BigDecimal，就已失真

BigDecimal运算必须指定Scale和RoundingMode

add()、subtract()、multiply()默认保留全部精度，但divide()不指定参数会抛ArithmeticException（除不尽时）。真实业务中几乎都需要显式控制小数位数和舍入方式。

典型用法：

• 货币计算统一用setScale(2, RoundingMode.HALF_UP)（银行家舍入的常见替代）
• 税率计算可能需要setScale(6, RoundingMode.HALF_EVEN)避免累积偏差
• 避免用RoundingMode.UP或.DOWN，它们偏向单向，容易引发审计问题

BigDecimal price = new BigDecimal("199.99");
BigDecimal taxRate = new BigDecimal("0.075");
BigDecimal tax = price.multiply(taxRate).setScale(2, RoundingMode.HALF_UP);
// 结果是 "15.00"，不是 "14.99925"

Math和BigDecimal混用时注意类型穿透

一旦开始用BigDecimal，就别中途切回double。比如把BigDecimal转成doubleValue()再塞给Math.sqrt()，精度就彻底丢了。

替代方案：

• 开方、幂运算等复杂函数，优先查Apache Commons Math的BigReal或自实现牛顿迭代（BigDecimal本身不提供）
• 简单比较大小用compareTo()而非doubleValue()再比较，避免NaN或溢出
• 日志打印时用toPlainString()而不是toString()，防止科学计数法干扰可读性

最常被忽略的一点：数据库字段类型和Java类型要严格对应。定义为DECIMAL(10,2)的列，Java端必须用BigDecimal接收，哪怕你暂时只做加减——因为未来某天加个乘法或除法，double就会悄悄污染整个计算链。