问题描述
在做四舍五入的时候遇到个问题,如下代码块,得出的结果是5.55,ROUND_HALF_UP在API上不是讲---((向“最接近的”数字舍入，如果与两个相邻数字的距离相等，则为向上舍入的舍入模式。如果舍弃部分 >= 0.5，则舍入行为与 ROUND_UP 相同；否则舍入行为与 ROUND_DOWN 相同。注意，这是我们大多数人在小学时就学过的舍入模式。 ))为什么结果不是5.56?还请老鸟不吝啬赐教啊,谢谢了.BigDecimal b = new BigDecimal(5.555);b = b.setScale(2, BigDecimal.ROUND_HALF_UP);System.out.println(b); 问题补充：dk101 写道
解决方案
看到楼主的这个问题，我也很是惊讶，应该是输出“5.56”才对的呀，怎么会是“5.55”呢？不相信之余，将代码运行了一次，结果真是“5.55”。我想这个问题的原因应该是处在创建对象b时，就这个代码“new BigDecimal(5.555); ”，我将其改成“new BigDecimal("5.555");”后，输出结果为“5.56”。不明白个中原因，只好查看API文档，原来是这样（下面是从API文档中拷贝的解释）：BigDecimalpublic BigDecimal(double val)将 double 转换为 BigDecimal，后者是 double 的二进制浮点值准确的十进制表示形式。返回的 BigDecimal 的标度是使 (10scale × val) 为整数的最小值。 注： 此构造方法的结果有一定的不可预知性。有人可能认为在 Java 中写入 new BigDecimal(0.1) 所创建的 BigDecimal 正好等于 0.1（非标度值 1，其标度为 1），但是它实际上等于 0.1000000000000000055511151231257827021181583404541015625。这是因为 0.1 无法准确地表示为 double（或者说对于该情况，不能表示为任何有限长度的二进制小数）。这样，传入 到构造方法的值不会正好等于 0.1（虽然表面上等于该值）。 另一方面，String 构造方法是完全可预知的：写入 new BigDecimal("0.1") 将创建一个 BigDecimal，它正好 等于预期的 0.1。因此，比较而言，通常建议优先使用 String 构造方法。 当 double 必须用作 BigDecimal 的源时，请注意，此构造方法提供了一个准确转换；它不提供与以下操作相同的结果：先使用 Double.toString(double) 方法，然后使用 BigDecimal(String) 构造方法，将 double 转换为 String。要获取该结果，请使用 static valueOf(double) 方法。 参数：val - 要转换为 BigDecimal 的 double 值。 抛出： NumberFormatException - 如果 val 为无穷大或 NaN。原因是，“此构造方法的结果有一定的不可预知性”，还真是憋闷，不知我的理解对否，请楼主参考。
解决方案二：
可以去学习一下httpclient 比较好的文章http://www.blogjava.net/Alpha/archive/2007/01/22/95216.html
解决方案三：
这个。。。5.555约等于5.554999999999999999999999999