关于Double, Float的进度问题

Double，Float都是由2进制数表示10进制的数，所以很多10进制数表示不完全，如0.3F实际上是 0.300000011920928955078125，所在在计算以及比较的时候会出错。解决这样的方法有2种：

一.  将Double, Float在计算的时候先转换成String然后传入BigDecimal 然后再进行计算这样可以保证不会有进度问题。

主要介绍下：BigDecimal的实现原理：当将Double, Float存入BigDecimal的时候，Java是用2进制保存的，所以会有误差。这时把Double, Float转成String或 用BigDecimal.valueOf(Double)(只用于double类型) 将数据放入BigDecimal后，再用BigDecimal计算。

关于BigDecimal的四舍五入：

BigDecimal b = new BigDecimal(Double.toString(double类型));

b.divide(BigDecimal.ONE, scale, BigDecimal.ROUND_HALF_UP)

这个可以完成四舍五入。

如果用这个函数BigDecimal.round(MathContext mc) 不能完成通常意味上的四舍五入。

因为：

一般情况下，当准确结果（在除法中，可能有无限多位）比返回的数值具有更多位数时，舍入模式和精度设置确定操作如何返回具有有限位数的结果。 首先，MathContext 的 precision 设置指定要返回的总位数；这确定了结果的精度。位数计数从准确结果的最左边的非零数字开始。舍入模式确定丢弃的尾部位数如何影响返回的结果。

摘自SCDN:---------

public BigDecimal(double val)

    将 double 转换为 BigDecimal，后者是 double 的二进制浮点值准确的十进制表示形式。返回的 BigDecimal 的标度是使 (10scale × val) 为整数的最小值。
      1. 此构造方法的结果有一定的不可预知性。有人可能认为在 Java 中写入 new BigDecimal(0.1) 所创建的 BigDecimal 正好等于 0.1（非标度值 1，其标度为 1），但是它实际上等于 0.1000000000000000055511151231257827021181583404541015625。这是因为 0.1 无法准确地表示为 double（或者说对于该情况，不能表示为任何有限长度的二进制小数）。这样，传入 到构造方法的值不会正好等于 0.1（虽然表面上等于该值）。
      2. 另一方面，String 构造方法是完全可预知的：写入 new BigDecimal("0.1") 将创建一个 BigDecimal，它正好 等于预期的 0.1。因此，比较而言，通常建议优先使用 String 构造方法。
      3. 当 double 必须用作 BigDecimal 的源时，请注意，此构造方法提供了一个准确转换；它不提供与以下操作相同的结果：先使用 Double.toString(double) 方法，然后使用 BigDecimal(String) 构造方法，将 double 转换为 String。要获取该结果，请使用 static valueOf(double) 方法。

经测试，如果采用
BigDecimal bd = new BigDecimal("39.555");
System.out.println(bd.doubleValue());
BigDecimal bd1 = bd.setScale(2, BigDecimal.ROUND_HALF_EVEN);
System.out.println(bd1.doubleValue());
以上数据都对

摘自SCDN:---------

二.  在计算精度不是要求很高的情况下，可以对最后的结果进行四舍五入，已达到所要的精度，这样结果会正确，但这种方法只实用于对精度要求不高的情况。