转载:浅谈Double 与 Float 的坑与解决办法

Posted liuxiaoddd

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了转载:浅谈Double 与 Float 的坑与解决办法相关的知识,希望对你有一定的参考价值。

老大说:谁要再用double定义商品金额,就自己收拾东西走

先看现象

涉及诸如float或者double这两种浮点型数据的处理时,偶尔总会有一些怪怪的现象,不知道大家注意过没,举几个常见的栗子:

典型现象(一):条件判断超预期

复制代码

1

2

System.out.println( 1f == 0.9999999f );   // 打印:false

System.out.println( 1f == 0.99999999f );  // 打印:true    纳尼?

典型现象(二):数据转换超预期

复制代码

1

2

3

4

float f = 1.1f;

double d = (double) f;

System.out.println(f);  // 打印:1.1

System.out.println(d);  // 打印:1.100000023841858  纳尼?

典型现象(三):基本运算超预期

复制代码

1

2

3

System.out.println( 0.2 0.7 ); 

// 打印:0.8999999999999999   纳尼?

典型现象(四):数据自增超预期

复制代码

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

float f1 = 8455263f;

for (int i = 0; i < 10; i++) {

    System.out.println(f1);

    f1++;

}

// 打印:8455263.0

// 打印:8455264.0

// 打印:8455265.0

// 打印:8455266.0

// 打印:8455267.0

// 打印:8455268.0

// 打印:8455269.0

// 打印:8455270.0

// 打印:8455271.0

// 打印:8455272.0

float f2 = 84552631f;

for (int i = 0; i < 10; i++) {

    System.out.println(f2);

    f2++;

}

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

//    打印:8.4552632E7   纳尼?不是 +1了吗?

看到没,这些简单场景下的使用情况都很难满足我们的需求,所以说用浮点数(包括doublefloat)处理问题有非常多隐晦的坑在等着咱们!

怪不得技术总监发狠话:谁要是敢在处理诸如 商品金额订单交易、以及货币计算时用浮点型数据(double/float),直接让我们走人!


原因出在哪里?

我们就以第一个典型现象为例来分析一下:

复制代码

System.out.println( 1f == 0.99999999f );

直接用代码去比较10.99999999,居然打印出true

这说明了什么?这说明了计算机压根区分不出来这两个数。这是为什么呢?

我们不妨来简单思考一下:

我们知道输入的这两个浮点数只是我们人类肉眼所看到的具体数值,是我们通常所理解的十进制数,但是计算机底层在计算时可不是按照十进制来计算的,学过基本计组原理的都知道,计算机底层最终都是基于像010100100100110011011这种01二进制来完成的。

所以为了搞懂实际情况,我们应该将这两个十进制浮点数转化到二进制空间来看一看。

十进制浮点数转二进制 怎么转、怎么计算,我想这应该属于基础计算机进制转换常识,在 《计算机组成原理》 类似的课上肯定学过了,咱就不在此赘述了,直接给出结果(把它转换到IEEE 754 Single precision 32-bit,也就float类型对应的精度)

复制代码

1.0(十进制)
    ↓
00111111 10000000 00000000 00000000(二进制)
    ↓
0x3F800000(十六进制)

复制代码

0.99999999(十进制)
    ↓
00111111 10000000 00000000 00000000(二进制)
    ↓
0x3F800000(十六进制)

果不其然,这两个十进制浮点数的底层二进制表示是一毛一样的,怪不得==的判断结果返回true

但是1f == 0.9999999f返回的结果是符合预期的,打印false,我们也把它们转换到二进制模式下看看情况:

复制代码

1.0(十进制)
    ↓
00111111 10000000 00000000 00000000(二进制)
    ↓
0x3F800000(十六进制)

复制代码

0.9999999(十进制)
    ↓
00111111 01111111 11111111 11111110(二进制)
    ↓
0x3F7FFFFE(十六进制)

哦,很明显,它俩的二进制数字表示确实不一样,这是理所应当的结果。

那么为什么0.99999999的底层二进制表示竟然是:00111111 10000000 00000000 00000000呢?

这不明明是浮点数1.0的二进制表示吗?

这就要谈一下浮点数的精度问题了。


浮点数的精度问题!

学过 《计算机组成原理》 这门课的小伙伴应该都知道,浮点数在计算机中的存储方式遵循IEEE 754 浮点数计数标准,可以用科学计数法表示为:

只要给出:符号(S)阶码部分(E)尾数部分(M) 这三个维度的信息,一个浮点数的表示就完全确定下来了,所以floatdouble这两种浮点数在内存中的存储结构如下所示:

1、符号部分(S)

0-正  1-负

2、阶码部分(E)(指数部分)

  • 对于float型浮点数,指数部分8位,考虑可正可负,因此可以表示的指数范围为-127 ~ 128
  • 对于double型浮点数,指数部分11位,考虑可正可负,因此可以表示的指数范围为-1023 ~ 1024

3、尾数部分(M)

浮点数的精度是由尾数的位数来决定的:

  • 对于float型浮点数,尾数部分23位,换算成十进制就是 2^23=8388608,所以十进制精度只有6 ~ 7位;
  • 对于double型浮点数,尾数部分52位,换算成十进制就是 2^52 = 4503599627370496,所以十进制精度只有15 ~ 16

所以对于上面的数值0.99999999f,很明显已经超过了float型浮点数据的精度范围,出问题也是在所难免的。


精度问题如何解决

所以如果涉及商品金额交易值货币计算等这种对精度要求很高的场景该怎么办呢?

方法一:用字符串或者数组解决多位数问题

校招刷过算法题的小伙伴们应该都知道,用字符串或者数组表示大数是一个典型的解题思路。

比如经典面试题:编写两个任意位数大数的加法、减法、乘法等运算

这时候我们我们可以用字符串或者数组来表示这种大数,然后按照四则运算的规则来手动模拟出具体计算过程,中间还需要考虑各种诸如:进位借位符号等等问题的处理,确实十分复杂,本文不做赘述。

方法二:Java的大数类是个好东西

JDK早已为我们考虑到了浮点数的计算精度问题,因此提供了专用于高精度数值计算的大数类来方便我们使用。

在前文《不瞒你说,我最近跟Java源码杠上了》中说过,Java的大数类位于java.math包下:

可以看到,常用的BigInteger 和 BigDecimal就是处理高精度数值计算的利器。

复制代码

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

BigDecimal num3 = new BigDecimal( Double.toString( 1.0f ) );

BigDecimal num4 = new BigDecimal( Double.toString( 0.99999999f ) );

System.out.println( num3 == num4 );  // 打印 false

BigDecimal num1 = new BigDecimal( Double.toString( 0.2 ) );

BigDecimal num2 = new BigDecimal( Double.toString( 0.7 ) );

// 加

System.out.println( num1.add( num2 ) );  // 打印:0.9

// 减

System.out.println( num2.subtract( num1 ) );  // 打印:0.5

// 乘

System.out.println( num1.multiply( num2 ) );  // 打印:0.14

// 除

System.out.println( num2.divide( num1 ) );  // 打印:3.5

当然了,像BigInteger 和 BigDecimal这种大数类的运算效率肯定是不如原生类型效率高,代价还是比较昂贵的,是否选用需要根据实际场景来评估。

“decimal   类型是适合财务和货币计算的   128   位数据类型。”

当然,decimal在大多数情况下是安全的,但浮点数在理论上是不安全的。

至于精度误差造成的显示问题,则是很容易修补的。浮点数会带来的问题以及整型能避免的问题就是一个:

譬如说从A帐户转账到B帐户,经计算得出结果是3.788888888888888元,那么我们从A帐户扣除这么多钱,B帐户增加这么多钱,但事实上A帐户不一定会扣除准确的数值,例如A帐户的金额在100000000000,那么这个时候100000000000   -   3.788888888888888运算结果很有可能是99999999996.211111111111112。而这个时候B帐户的金额为0则很有可能加上准确的数值,如3.788888888888888,这样一来,0.011111111111112元钱就会不见了,日积月累的,差额就会越来越大。

double是64位的,比single-32位精度高  

  decimal128位高精度浮点数,常用于金融运算,不会出现浮点数计算的误差

,decimal   类型具有更高的精度和更小的范围,这使它适合于财务和货币计算。

转载自:

浅谈:Double 与 Float 的坑与解决办法 - 有间猫 - 博客园

decimal,float和double的区别_flyingdream123的专栏-CSDN博客_decimal和double区别

以上是关于转载:浅谈Double 与 Float 的坑与解决办法的主要内容,如果未能解决你的问题,请参考以下文章

转载:浅谈Double 与 Float 的坑与解决办法

#私藏项目实操分享# Java实战系列「技术盲区」Double与Float的坑与解决办法以及BigDecimal的取而代之!

Java盲点攻克「数值浮点数精度系列」Double与Float的坑与解决办法以及BigDecimal的取而代之!

记录某项目中的踩坑与解决(持续更新)

MySQL_远程连接的坑与路

jar包的多层级maven依赖的坑与正确传递方法