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)  来替代。

下面是楼主和留言者其他的讨论

1L说的是对的，浮点数的精度有限，在运算过程中很有可能会损失精度，因此Java提供了BigDecimal来精确地进行小数的表示和计算。但不能说BigDecimal会损失double的精度，这是绝对错误的。

你的例子中301353.05生成的BigDecimal对象之所以打印出来不是301353.05而是301353.0499999999883584678173065185546875，是因为后者就是301353.05的内存位模式的值，是Java double类型所能够表示最接近301353.05的值。也就是说，301353.05在内存中原本就是那样的。

String.valueOf()之所以好像没有损失精度，是因为它最终会调用Doubled的toString()方法，这个方法会对double的内部值做近似运算，从而让打印出来的字符串看起来更“合理”，例如计算机会觉得301353.04999xxxxx更有可能应该是301353.05，因此将结果近似为它。具体看JDK文档中Double.toString(double)的方法说明。

我可以写一个跟你的例子相似的反例，来说明String.valueOf()并不像你想象的那么“精确”。

1 2 3

double  d =  301353 .0499999999883584678173065185546875d; System.out.println(String.valueOf(d)); System.out.println( new  java.math.BigDecimal(d));

第一句打印的是301353.05，第二句却打印出了d的准确值。结合你自己的例子，你觉得到底哪个更精确呢？