背景
在博客 恶心的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的准确值。结合你自己的例子,你觉得到底哪个更精确呢?