背景
我们在使用金额计算或者展示金额的时候经常会使用 BigDecimal,也是涉及金额时非常推荐的一个类型。
BigDecimal 自身也提供了很多构造器方法,这些构造器方法使用不当可能会造成不必要的麻烦甚至是金额损失,从而引起事故资损。
事故详情
接下来我们看下收银台出的一起事故。
-
问题描述
收银台计算商品金额报错,导致订单无法支付。 -
事故级别
P0 -
事故过程如下:
13:44,接到报警,订单支付失败,支付可用率降至 60%
13:50,迅速回滚上线代码,恢复正常
14:20,检视代码,预发布验证发现问题点
14:58,修改问题代码上线,线上恢复
-
故障原因
BigDecimal 在金额计算中丢失精度。
分析
代码复现:
public static void main(String[] args) {
BigDecimal bigDecimal=new BigDecimal(88);
System.out.println(bigDecimal);
bigDecimal=new BigDecimal("8.8");
System.out.println(bigDecimal);
bigDecimal=new BigDecimal(8.8);
System.out.println(bigDecimal);
}
执行结果如下:
我们先看下BigDecimal的实例构造方法:
@IntrinsicCandidate
public static long doubleToLongBits(double value) {
if (!isNaN(value)) {
return doubleToRawLongBits(value);
}
return 0x7ff8000000000000L;
}
@IntrinsicCandidate
public static native long doubleToRawLongBits(double value);
问题就出在 doubleToRawLongBits 这个方法上,在 jdk 中 double 类(float 与 int 对应)中提供了 double 与 long 转换,doubleToRawLongBits 就是将 double 转换为 long,这个方法是原始方法(底层不是 java 实现,是 c++ 实现的)。
BigDecimal 在处理的时候把十进制小数扩大 N 倍让它在整数上进行计算,并保留相应的精度信息。
- float 和 double 类型,主要是为了科学计算和工程计算而设计的,之所以执行二进制浮点运算,是为了在广泛的数值范围上提供较为精确的快速近和计算。
- 并没有提供完全精确的结果,所以不应该被用于精确的结果的场合。
- 当浮点数达到一定大的数,就会自动使用科学计数法,这样的表示只是近似真实数而不等于真实数。
- 当十进制小数位转换二进制的时候也会出现无限循环或者超过浮点数尾数的长度。
总结
在涉及到精度计算的过程中,我们尽量使用 String 类型来进行转换