bigdecimal加减乘除运算保留两位小数_小数精度丢失问题分析和解决

无论在什么业务中，钱?是非常重要的东西，对账的时候一定要对的上，不能这边少一分钱那边多一分钱。对于数值的计算，尤其是小数，floate和double都是禁止使用的。

阿里强制要求存放小数时使用 decimal，禁止使用 float 和 double。

说明：float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。

处理方式可以为：mysql 可以用 decimal ，如果你是用 java， 在商业计算中我们要用 java.math.BigDecimal，注意：如果需要精确计算，非要用String来构造BigDecimal不可！

那么到底是什么情况？为什么我们的账户一会少一分一会多一分(往往是少一分)，如何解决呢？

一个例子说明

废话不多说，当我们拿着一块钱去买了一根9毛的棒冰会发生啥？本来只剩1毛钱就不多了，老板还扣我0.000....0002分？上图：

问题原因

无论是我们本文提到的double，还是float，都是浮点数。

在计算机科学中，浮点(英语：floating point，缩写为FP)是一种对于实数的近似值数值表现法，由一个有效数字(即尾数)加上幂数来表示，通常是乘以某个基数的整数次指数得到。以这种表示法表示的数值，称为浮点数(floating-point number)。

划重点，⭐⭐⭐其实我觉得很好理解，我们之前说过，计算机计算加减乘除啊，都是用的加法器，实质都是二进制的加法处理。那么这里就有一个二进制表示的问题。试想，4，2，8之流都是2的幂次方，可以完美用二进制表示，计算当然不会出现问题。对于0，1，3，5之类也都可以用二进制来表示出来，所以，整数肯定是没问题的。

但是对于小数呢？1(2的0次方)、0.5(2的-1次方)、0.25(2的-2次方)、0.75(2的-1次方+2的-2次方)，那都是可以转换成二进制的小数：

但是如十进制的0.1，就无法用二进制准确的表示出来(你用2的次方来凑凑？)。因此只能使用近似值的方式表达。如果我们尝试着把10进制的0.1转化成二进制，会怎么转呢？

在十进制中，0.1如何计算出来的呢？

0.1 = 1 ÷ 10

那么二进制中也是同理：

1 ÷ 1010

我们回到小学的课堂，来列竖式吧：

       0.000110011...
      ------------------
1010 ) 1 0000
1010
       ------
1100
1010
          ----
10000
1010
            -----
1100
1010
              ----
10

很显然，除不尽，除出了一个无限循环小数：二进制的 0.0001100110011...

有的同学表示怀疑？这结果正确？

我写在这里当然正确啦，前面标注了是二进制，小数点后面一位就是-1次方依次计算，我们的0.1是不是介于(2的-3次方)和(2的-4次方)之间，那么显然是从小数点第四个开始有1。

好了，那么，如何在计算机中表示这个无限不循环的小数呢？只能考虑按照不同的精度保留不同的位数。

我们知道float是单精度的(JAVA中是32位)，double是双精度的(JAVA中是64位)。不同的精度，其实就是保留的有效数字位数不同，保留的位数越多，精度越高。

所以，浮点数在Java中是无法精确表示的，因为大部分浮点数转换成二进制是一个无限不循环的小数，只能通过保留精度的方式进行近似表示。

问题的解决

String 构造方法是完全可预知的：写入 newBigDecimal("0.1") 将创建一个 BigDecimal，它正好等于预期的 0.1。因此，比较而言，通常建议优先使用String构造方法。

使用BigDecimal(String val)！

//加法
public static BigDecimal add(double v1, double v2){
    BigDecimal b1 = new BigDecimal(Double.toString(v1));
    BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.add(b2);
}

//减法
public static BigDecimal sub(double v1,double v2){
    BigDecimal b1 = new BigDecimal(Double.toString(v1));
    BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.subtract(b2);
}

//乘法
public static BigDecimal mul(double v1,double v2){
    BigDecimal b1 = new BigDecimal(Double.toString(v1));
    BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.multiply(b2);
}

//除法
public static BigDecimal div(double v1,double v2){
    BigDecimal b1 = new BigDecimal(Double.toString(v1));
    BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.divide(b2,2,BigDecimal.ROUND_HALF_UP);//四舍五入,保留2位小数,应对除不尽的情况
}

那么，上面的精度丢失问题就迎刃而解了。但是除不尽怎么办？比如10.0除以这里的3.0，保留小数点后三位有效数字：

那么，每个用户得到的都是3.333元，三个用户加起来是得不到10块钱的。

对于除法，始终会产生除不尽的情况怎么办？有个词叫轧差

什么意思呢？举个简单例子。假如现在需要把10元分成3分，如果是10除以3这么除，会发现为3.33333无穷尽的3。这些数字完全无法在程序或数据库中进行精确的存储。

简单理解就是，当除不尽或需去除小数点的时候，前面的n-1笔(这里n=3)做四舍五入。最后一笔做兜底(总金额减去前面n-1笔之和)。这样保证总金额的不会丢失。

比如10块钱，三个用户分，前面两个用户只能各分到3.333块钱，最后一个用户分到3.334块钱。保证总额不变。是不是感觉很机智

好了，我们可以准确地管理我们的钱了。不过针对这个钱的问题，更机智的我选择保存钱的时候用分为单位来操作和保存，能少一事就少一事吧。当然了，有的时候必须用到小数的时候，请记住我们该如何使用哦~