java中进行金额的计算经常浮点数丢失精度,造成这种问题的原因应该与cpu对浮点数的计算方式有关,有下面的介绍: 从原理上来讲,任何一门语言对于浮点数的计算都是不精确的。 因为现在的Computer都是基于二进制数来存储计算的。 例如计算8+3时,Computer会转换为二进制的加法1000+11=1011,然后再转换为十进制数为11。 这种算法对于整数来说是不会产生误差的(如果不超过计算范围); 而对于浮点数计算有时就会产生误差。因为有的浮点数转换成为二进制时是一个无穷循环小数。 例如十进制的0.4,转换成为二进制为0.0110011001100110....,这样,在0.4+0.3时就不能准确的算出是0.7, 而是经过一些舍入处理才能得出正确结果,但经过多次运算误差产生的较大时, 即使经过一些舍入处理也不能得到精确的结果了。 既然这样,那么在java中为了保持精度需要怎样做呢? 一句话:用BigDecimal进行运算;BigDecimal的构造函数有下面几种: BigDecimal(BigInteger val) Translates a BigInteger into a BigDecimal. BigDecimal(BigInteger unscaledVal, int scale) Translates a BigInteger unscaled value and an int scale into a BigDecimal. BigDecimal(double val) Translates a double into a BigDecimal. BigDecimal(String val) Translates the String representation of a BigDecimal into a BigDecimal. 按照jdk帮助文档说明,如果采用double类型构造函数的话有可能丢失精度,推荐采用String类型的构造函数. Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.