float和double使用时的大坑

博主： Arvin
发布时间：2021 年 12 月 18 日
648 次浏览
暂无评论
5705字数
分类：日常软件开发

## 先看现象

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

##### **典型现象（一）：条件判断超预期**

```
System.out.println( 1f == 0.9999999f );   // 打印：false
System.out.println( 1f == 0.99999999f );  // 打印：true    纳尼？
```

##### **典型现象（二）：数据转换超预期**

```
float f = 1.1f;
double d = (double) f;
System.out.println(f);  // 打印：1.1
System.out.println(d);  // 打印：1.100000023841858  纳尼？
```

##### **典型现象（三）：基本运算超预期**

```
System.out.println( 0.2 + 0.7 );  // 打印：0.8999999999999999   纳尼？
```

##### **典型现象（四）：数据自增超预期**

```
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了吗？
```

看到没，这些简单场景下的使用情况都很难满足我们的需求，所以说用浮点数（包括 `double`和 `float`）处理问题有非常多 **隐晦的坑** 在等着咱们！

如果用在 **商品金额** 、 **订单交易** 、以及**货币计算** 时用浮点型数据（`double`/`float`），那这个就GG了！

## 分析原因

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

```
System.out.println( 1f == 0.99999999f );  // 打印：true
```

直接用代码去比较 `1`和 `0.99999999`，居然打印出 `true`！

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

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

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

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

**十进制浮点数转二进制** 怎么转、怎么计算，我想这应该属于基础计算机进制转换常识，在 **《计算机组成原理》** 类似的课上肯定学过了，咱就不在此赘述了，直接给出结果（把它转换到 `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 浮点数计数标准** ，可以用科学计数法表示为：

IEEE 浮点数标准是从逻辑上用三元组{S，E，M}来表示一个数 V 的，即 V =（-1）S×M×2E

只要给出： **符号（S）** 、 **阶码部分（E）** 、 **尾数部分（M）** 这三个维度的信息，一个浮点数的表示就完全确定下来了，所以 `float`和 `double`这两种浮点数在内存中的存储结构如下所示：

![float存储结构](http://www.jbea.cn/usr/uploads/2021/12/1434225272.png)

![double存储结构图](http://www.jbea.cn/usr/uploads/2021/12/4027289738.png)

**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.math`包下】

常用的 `BigInteger` 和 `BigDecimal`就是处理高精度数值计算的利器。

```
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`这种大数类的运算效率肯定是不如原生类型效率高，代价还是比较昂贵的，是否选用需要根据实际场景来评估。

如果有更多问题，请在评论区让我看到哇~

最后修改：2021 年 12 月 18 日

都滑到这里了，不点赞再走！？

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

float和double使用时的大坑

Arvin • 2021 年 12 月 18 日

## 先看现象

##### **典型现象（一）：条件判断超预期**

```
System.out.println( 1f == 0.9999999f );   // 打印：false
System.out.println( 1f == 0.99999999f );  // 打印：true    纳尼？
```

##### **典型现象（二）：数据转换超预期**

```
float f = 1.1f;
double d = (double) f;
System.out.println(f);  // 打印：1.1
System.out.println(d);  // 打印：1.100000023841858  纳尼？
```

##### **典型现象（三）：基本运算超预期**

```
System.out.println( 0.2 + 0.7 );  // 打印：0.8999999999999999   纳尼？
```

##### **典型现象（四）：数据自增超预期**

## 分析原因

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

```
System.out.println( 1f == 0.99999999f );  // 打印：true
```

直接用代码去比较 `1`和 `0.99999999`，居然打印出 `true`！

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

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

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

```
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 浮点数标准是从逻辑上用三元组{S，E，M}来表示一个数 V 的，即 V =（-1）S×M×2E

![float存储结构](http://www.jbea.cn/usr/uploads/2021/12/1434225272.png)

![double存储结构图](http://www.jbea.cn/usr/uploads/2021/12/4027289738.png)

**1、符号部分（S）**

`0`-正  `1`-负

**2、阶码部分（E）（指数部分）**

**3、尾数部分（M）**

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

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

## 精度问题如何解决

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

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

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

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

常用的 `BigInteger` 和 `BigDecimal`就是处理高精度数值计算的利器。

```
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`这种大数类的运算效率肯定是不如原生类型效率高，代价还是比较昂贵的，是否选用需要根据实际场景来评估。

如果有更多问题，请在评论区让我看到哇~

float和double使用时的大坑

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

Java基础之JDK的安装

开启Visual Studio Code编写jQuery语法提示

C#-WinForms实现手写板

使用GSAP实现滚动条交互动画

HTML从入门到精通 - 初识HTML

C#-WinForms实现手写板

来自唐能彪同学的项目总结

来自雷雄辉同学的项目总结

来自曾林小朋友的项目总结

来自欧阳宇同学的项目总结

float和double使用时的大坑

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

float和double使用时的大坑

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款