Java中的金额处理的精度问题（java金额比较大小方法）

1.BigDecimal的精度问题

分析一下上面代码的问题（注释的内容表示此语句的输出）

第一行：事实上，由于二进制无法精确地表示十进制小数0.1，但是编译器读到字符串"0.1"之后，必须把它转成8个字节的double值，因此，编译器只能用一个最接近的值来代替0.1了， 即0.1000000000000000055511151231257827021181583404541015625。因此，在运行时，传给BigDecimal构造函数的真正的数值是0.1000000000000000055511151231257827021181583404541015625。

第二行：BigDecimal能够正确地把字符串转化成真正精确的浮点数。

第三行：问题在于Double.toString会使用一定的精度来四舍五入double，然后再输出。会。Double.toString(0.1000000000000000055511151231257827021181583404541015625)输出的事实上是"0.1"，因此生成的 BigDecimal表示的数也是0.1。

第四行：基于前面的分析，事实上这一行代码等价于第三行

结论：

1.如果你希望BigDecimal能够精确地表示你希望的数值，那么一定要使用字符串来表示小数，并传递给BigDecimal的构造函数。

2.如果你使用Double.toString来把double转化字符串，然后调用BigDecimal(String)，这个也是不靠谱的，它不一定按你的想法工作。

3.如果你不是很在乎是否完全精确地表示，并且使用了BigDecimal(double)，那么要注意double本身的特例，double的规范本身定义了几个特殊的double值(Infinite，-Infinite，NaN)，不要把这些值传给BigDecimal，否则会抛出异常。

2.把double强制转化成int，难道不是扔掉小数部分吗？

原因还是在于二进制无法精确地表示某些十进制小数，因此1023.99999999999999在编译之后的double值变成了1024。

所以，把double强制转化成int确实是扔掉小数部分，但是你写在代码中的值，并不一定是编译器生成的真正的double值。