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值 。