当前位置: 代码迷 >> Java相关 >> Java中关于 BigDecimal 的一个以致double精度损失的"bug"
  详细解决方案

Java中关于 BigDecimal 的一个以致double精度损失的"bug"

热度:773   发布时间:2016-04-22 20:18:10.0
Java中关于 BigDecimal 的一个导致double精度损失的"bug"

背景

     在博客 恶心的0.5四舍五入问题 一文中看到一个关于 0.5 不能正确的四舍五入的问题。主要说的是 double 转换到 BigDecimal 后,进行四舍五入得不到正确的结果:

public class BigDecimalTest {    public static void main(String[] args){        double d = 301353.05;        BigDecimal decimal = new BigDecimal(d);        System.out.println(decimal);//301353.0499999999883584678173065185546875        System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.0    }}

输出的结果为:

301353.0499999999883584678173065185546875
301353.0

这个结果显然不是我们所期望的,我们希望的是得到 301353.1 。

原因

     允许明眼人一眼就看出另外问题所在——BigDecimal的构造函数 public BigDecimal(double val) 损失了double 参数的精度,最后才导致了错误的结果。所以问题的关键是:BigDecimal的构造函数 public BigDecimal(double val) 损失了double 参数的精度。

解决之道

因为上面找到了原因,所以也就很好解决了。只要防止了 double 到 BigDecimal 的精度的损失,也就不会出现问题。

1)很容易想到第一个解决办法:使用BigDecimal的以String为参数的构造函数:public BigDecimal(String val)  来替代。

public class BigDecimalTest {    public static void main(String[] args){        double d = 301353.05;        System.out.println(new BigDecimal(new Double(d).toString()));        System.out.println(new BigDecimal("301353.05"));        System.out.println(new BigDecimal("301353.895898895455898954895989"));    }}

输出结果:

301353.05
301353.05
301353.895898895455898954895989

我们看到了没有任何的精度损失,四舍五入也就肯定不会出错了。

2)BigDecimal的构造函数 public BigDecimal(double val) 会损失了double 参数的精度,这个也许应该可以算作是 JDK 中的一个 bug 了。既然存在bug,那么我们就应该解决它。上面的办法是绕过了它。现在我们实现自己的 double 到 BigDecimal 的转换,并且保证在某些情况下可以完全不损失 double 的精度。

import java.math.BigDecimal;public class BigDecimalUtil {        public static BigDecimal doubleToBigDecimal(double d){        String doubleStr = String.valueOf(d);        if(doubleStr.indexOf(".") != -1){            int pointLen = doubleStr.replaceAll("\\d+\\.", "").length();    // 取得小数点后的数字的位数            pointLen = pointLen > 16 ? 16 : pointLen;    // double最大有效小数点后的位数为16            double pow = Math.pow(10, pointLen);
       long tmp = (long)(d * pow);
return new BigDecimal(tmp).divide(new BigDecimal(pow)); } return new BigDecimal(d); } public static void main(String[] args){// System.out.println(doubleToBigDecimal(301353.05));// System.out.println(doubleToBigDecimal(-301353.05));// System.out.println(doubleToBigDecimal(new Double(-301353.05)));// System.out.println(doubleToBigDecimal(301353));// System.out.println(doubleToBigDecimal(new Double(-301353))); double d = 301353.05;//5898895455898954895989; System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); }}

输出结果:

301353.05
301353.05
301353.05
301353.05
301353.0499999999883584678173065185546875

上面我们自己写了一个工具类,实现了 double 到 BigDecimal 的“无损失”double精度的转换。方法是将小数点后有有效数字的double先转换到小数点后没有有效数字的double,然后在转换到 BigDecimal ,之后使用BigDecimal的 divide 返回之前的大小。

上面的结果看起来好像十分的完美,但是其实是存在问题的。上面我们也说到了“某些情况下可以完全不损失 double 的精度”,我们先看一个例子:

    public static void main(String[] args){        double d = 301353.05;        System.out.println(doubleToBigDecimal(d));        System.out.println(d);        System.out.println(new Double(d).toString());        System.out.println(new BigDecimal(new Double(d).toString()));        System.out.println(new BigDecimal(d));                System.out.println("=========================");        d = 301353.895898895455898954895989;        System.out.println(doubleToBigDecimal(d));        System.out.println(d);        System.out.println(new Double(d).toString());        System.out.println(new BigDecimal(new Double(d).toString()));        System.out.println(new BigDecimal(d));        System.out.println(new BigDecimal("301353.895898895455898954895989"));                System.out.println("=========================");        d = 301353.46899434;        System.out.println(doubleToBigDecimal(d));        System.out.println(d);        System.out.println(new Double(d).toString());        System.out.println(new BigDecimal(new Double(d).toString()));        System.out.println(new BigDecimal(d));                System.out.println("=========================");        d = 301353.45789666;        System.out.println(doubleToBigDecimal(d));        System.out.println(d);        System.out.println(new Double(d).toString());        System.out.println(new BigDecimal(new Double(d).toString()));        System.out.println(new BigDecimal(d));    }

输出结果:

301353.05
301353.05
301353.05
301353.05
301353.0499999999883584678173065185546875
=========================
301353.89589889544
301353.89589889545
301353.89589889545
301353.89589889545
301353.895898895454593002796173095703125
301353.895898895455898954895989
=========================
301353.46899434
301353.46899434
301353.46899434
301353.46899434
301353.4689943399862386286258697509765625
=========================
301353.45789666
301353.45789666
301353.45789666
301353.45789666
301353.4578966600238345563411712646484375
我们可以看到:我们自己实现的 doubleToBigDecimal 方法只有在 double 的小数点后的数字位数比较少时(比如只有5,6位),才能保证完全的不损失精度

在 double 的小数点后的数字位数比较多时,d * pow 会存在精度损失,所以最终的结果也会存在精度损失。所以如果小数点后的位数比较多时,还是使用 BigDecimal的 String 参数的构造函数为好,只有在小数点后的位数比较少时,才可以采用自己实现的 doubleToBigDecimal 方法。

因为我们看到原始的double的转换之后的BigDecimal的数字的最后一位一个时5,一个是4,原因是在上面的转换方法中:

long tmp = (long)(d * pow);

这一步可能存在很小的精度损失,因为 d 是一个 double ,d * pow 之后还是一个 double(但是小数点之后都是0了,所以到long的转换没有精度损失) ,所以会存在很小的精度损失(double的计算总是有可能存在精度损失的)。但是这个精度损失和 BigDecimal的构造函数 public BigDecimal(double val) 的精度损失相比而言,不会显得那么的突兀(也许我们自己写的doubleToBigDecimal也是存在问题的,欢迎指点)。

总结

如果需要保证精度,最好是不要使用BigDecimal的double参数的构造函数,因为存在损失double参数精度的可能,最好是使用BigDecimal的String参数的构造函数。最好是杜绝使用BigDecimal的double参数的构造函数。

 

后记:

     其实说这是BigDecimal的一个bug,有标题党的嫌疑,最多可以算作是BigDecimal的一个“坑”。

3楼digdeep
补充一个例子(说明是BigDecimal的以double为参数的构造是个坑):,double d = 301353.05;,System.out.println(new BigDecimal(new Double(d).toString()));,System.out.println(new BigDecimal(String.valueOf(d)));,System.out.println(new BigDecimal(d));,,结果:,301353.05,301353.05,301353.0499999999883584678173065185546875
2楼xmodygetz
作者对问题的理解存在问题。,并不是BigDecimal精度存在误差,而是传入的double本身就是那个值,301353.05是你写入的十进制数。,在编译时必然要转换为二进制数。,而.05在二进制小数表示法中不可能有精确值,所以必然有损失。,,使用浮点数表示准确值本身就是错误的。,将301353.05作为30135305进行计算,显示时放上小数点就不会出现任何问题,即定点表示法。
Re: digdeep
@xmodygetz,我不太同意你的看法,我的看法是:BigDecimal的构造函数 public BigDecimal(double val) 的导致了精度损失,我们应该杜绝使用它。我们应该使用String 参数的构造函数:public BigDecimal(String val),,也就是对于 double 到 BigDecimal 的转换,需要先将 Double 转换到 String, 然后在使用 public BigDecimal(String val) 来构造。这样就不会导致double的精度损失。也能保证:只要double能表示的,BigDecimal就能不损失精度的表示,前提是使用正确的构造函数。如果使用了错误的构造函数,那么会造成,本来double可以精确表示的,到了BigDecimal反而不能了。
Re: 菩提树下的杨过
@xmodygetz,我比较认同这个观点,0.5用2进制表示,不管用什么语言,计算机内部是无法100%表示的,问题在于setScale方法本身的实现不严谨。
1楼digdeep
在补充一个例子说明BigDecimal的以double为参数的构造函数是个坑:,double d = 301353.05;,System.out.println(new BigDecimal(new Double(d).toString()));,System.out.println(new BigDecimal(String.valueOf(d)));,System.out.println(new BigDecimal(d));,,System.out.println(new BigDecimal(new Double(d).toString()).multiply(new BigDecimal(100)));,System.out.println(new BigDecimal(d).multiply(new BigDecimal(100)));,结果:,301353.05,301353.05,301353.0499999999883584678173065185546875,30135305.00,30135304.9999999988358467817306518554687500,这样就排除了 toString() 方法的影响了,后面的两行代码,明显就说明了是构造函数导致了精度损失了。
  相关解决方案