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

先看现象

涉及诸如 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），直接让我们走人！

原因出在哪里？

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

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

直接用代码去比较 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 浮点数计数标准，可以用科学计数法表示为：

<svg xmlns="http://www.w3.org/2000/svg" viewbox="0 -843.8 5031.2 843.8" style="vertical-align: 0px;width: 11.383ex;height: 1.909ex;">
 <g stroke="currentColor" fill="currentColor" stroke-width="0" transform="matrix(1 0 0 -1 0 0)">
  <g>
   <g>
    <path d="M213 578L200 573Q186 568 160 563T102 556H83V602H102Q149 604 189 617T245 641T273 663Q275 666 285 666Q294 666 302 660V361L303 61Q310 54 315 52T339 48T401 46H427V0H416Q395 3 257 3Q121 3 100 0H88V46H114Q136 46 152 46T177 47T193 50T201 52T207 57T213 61V578Z"></path>
    <path d="M78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60Z"></path>
   </g>
   <g transform="translate(778, 0)">
    <path d="M289 629Q289 635 232 637Q208 637 201 638T194 648Q194 649 196 659Q197 662 198 666T199 671T201 676T203 679T207 681T212 683T220 683T232 684Q238 684 262 684T307 683Q386 683 398 683T414 678Q415 674 451 396L487 117L510 154Q534 190 574 254T662 394Q837 673 839 675Q840 676 842 678T846 681L852 683H948Q965 683 988 683T1017 684Q1051 684 1051 673Q1051 668 1048 656T1045 643Q1041 637 1008 637Q968 636 957 634T939 623Q936 618 867 340T797 59Q797 55 798 54T805 50T822 48T855 46H886Q892 37 892 35Q892 19 885 5Q880 0 869 0Q864 0 828 1T736 2Q675 2 644 2T609 1Q592 1 592 11Q592 13 594 25Q598 41 602 43T625 46Q652 46 685 49Q699 52 704 61Q706 65 742 207T813 490T848 631L654 322Q458 10 453 5Q451 4 449 3Q444 0 433 0Q418 0 415 7Q413 11 374 317L335 624L267 354Q200 88 200 79Q206 46 272 46H282Q288 41 289 37T286 19Q282 3 278 1Q274 0 267 0Q265 0 255 0T221 1T157 2Q127 2 95 1T58 0Q43 0 39 2T35 11Q35 13 38 25T43 40Q45 46 65 46Q135 46 154 86Q158 92 223 354T289 629Z"></path>
   </g>
   <g transform="translate(1829, 0)">
    <path d="M78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60Z"></path>
   </g>
   <g transform="translate(2273.7, 0)">
    <path d="M78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60Z"></path>
   </g>
   <g transform="translate(2718.3, 0)">
    <path d="M78 60Q78 84 95 102T138 120Q162 120 180 104T199 61Q199 36 182 18T139 0T96 17T78 60Z"></path>
   </g>
   <g transform="translate(3163, 0)">
    <path d="M630 29Q630 9 609 9Q604 9 587 25T493 118L389 222L284 117Q178 13 175 11Q171 9 168 9Q160 9 154 15T147 29Q147 36 161 51T255 146L359 250L255 354Q174 435 161 449T147 471Q147 480 153 485T168 490Q173 490 175 489Q178 487 284 383L389 278L493 382Q570 459 587 475T609 491Q630 491 630 471Q630 464 620 453T522 355L418 250L522 145Q606 61 618 48T630 29Z"></path>
   </g>
   <g transform="translate(3941, 0)">
    <g>
     <path d="M109 429Q82 429 66 447T50 491Q50 562 103 614T235 666Q326 666 387 610T449 465Q449 422 429 383T381 315T301 241Q265 210 201 149L142 93L218 92Q375 92 385 97Q392 99 409 186V189H449V186Q448 183 436 95T421 3V0H50V19V31Q50 38 56 46T86 81Q115 113 136 137Q145 147 170 174T204 211T233 244T261 278T284 308T305 340T320 369T333 401T340 431T343 464Q343 527 309 573T212 619Q179 619 154 602T119 569T109 550Q109 549 114 549Q132 549 151 535T170 489Q170 464 154 447T109 429Z"></path>
    </g>
    <g transform="translate(500, 363) scale(0.707)">
     <path d="M492 213Q472 213 472 226Q472 230 477 250T482 285Q482 316 461 323T364 330H312Q311 328 277 192T243 52Q243 48 254 48T334 46Q428 46 458 48T518 61Q567 77 599 117T670 248Q680 270 683 272Q690 274 698 274Q718 274 718 261Q613 7 608 2Q605 0 322 0H133Q31 0 31 11Q31 13 34 25Q38 41 42 43T65 46Q92 46 125 49Q139 52 144 61Q146 66 215 342T285 622Q285 629 281 629Q273 632 228 634H197Q191 640 191 642T193 659Q197 676 203 680H757Q764 676 764 669Q764 664 751 557T737 447Q735 440 717 440H705Q698 445 698 453L701 476Q704 500 704 528Q704 558 697 578T678 609T643 625T596 632T532 634H485Q397 633 392 631Q388 629 386 622Q385 619 355 499T324 377Q347 376 372 376H398Q464 376 489 391T534 472Q538 488 540 490T557 493Q562 493 565 493T570 492T572 491T574 487T577 483L544 351Q511 218 508 216Q505 213 492 213Z"></path>
    </g>
   </g>
  </g>
 </g>
</svg>

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

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

每天进步一点点，Peace！ 

2020.04.09晚

最后，再附上我历时三个月总结的 Java 面试 + Java 后端技术学习指南，这是本人这几年及春招的总结，目前，已经拿到了大厂offer，拿去不谢！

下载方式

1. 首先扫描下方二维码

2. 后台回复「Java面试」即可获取

原文地址：https://sihai.blog.csdn.net/article/details/109465496