0.05+0.01＝0.060000000000000005
才发现Java的double原来精度那么蛋疼. 网上推荐BigDecimal代替double, 果然不错, 那就用BigDecimal替换. 等所有的double都换之后, 狗血的事情发生了, BigDecimal是如此的慢, 以至于跑一个用例花了之前N倍的时间, 怎么办, 只能用一个折中的办法, 数值表示仍然用double, 数值计算用BigDecimal。
既然Java的double问题那么多, 我当前系统用double表示数值, 会不会出现偏差? 如果Java中采用BigDecimal效率这么低, 那些大型交易所, 性能要求极高, 如何控制延迟呢? 或者还有其他更好的技术？？
double奇葩的精度. 试一下C语言的，结果如下：
printf("%lf", 0.01 + 0.05); #输出结果为0.060000.
怎么会这样呢？？是精度, 保留的精度不对, 于是设定保留小数点后18位, 因为java的输出小数点后有18位：
printf("%.18lf", 0.01 + 0.05); #输出结果为0.060000000000000005.
试了下python也是如此, 毕竟编程语言基本采用IEEE754标准, 存储方式相同, 计算也都由CPU完成, 跟语言无关, 而是跟IEEE754标准有关?接着看下Java语言：
System.out.println(0.09 + 0.01); #输出结果为0.09999999999999999.
但是, 如果取小数点后10位以内, 结果还是好的, 而且一般现实也不需要那么高的精度, 但是, 倘若每次计算都做一次round, 势必性能大打折扣！然而不做round, 的确是不严谨的作法, 如果是支付场景, 0.09+0.01<0.1, 那么这次交易就完成不了, 这是绝对不能容忍的错误！
谈了现象, 再谈谈原因, 其实很简单, 10进制的世界, 对于0, 1的世界的计算机来说, 呵呵~~
尾数整数能表示最大值是2^54−1, 即当你的整数部分大于或接近2^54−1时, 如果有小数, 则小数精度丢失非常严重.:
在整数部分不太大的情况下, double可以保证精度丢失微乎其微；而当整数部分过大时, 小数部分会做非常粗暴省略.
double之所以会产生精度的丢失, 最根本的因素是用于表示小数的二进制位数不够, 然后做round, 造成丢失.
使用double, 保留小数最多不超过3位, 勉勉强强应付几百个亿, 那对于金融, 科学计算领域, 可以想见, double已经不能满足需求了！因此, 采用Java BigDecimail是非常有必要的.
申明：这里提到的double都是采用IEEE754规范的64位浮点数.
