Improper use of BigDecimal caused P0 accident!

Recommended today

 Reduce  try-catch , This is grace ！

 An addictive new generation of development artifacts , Say goodbye to Controller、Service、Dao Other methods 

SpringBoot Realize face recognition function 

 believe me , Use  Stream  Can really make the code more elegant ！

 The most detailed thread pool in the whole network  ThreadPoolExecutor  Reading ！

 Batch splitting with multithreading  List  Import database , Efficiency bars ！

Source of the article ：https://c1n.cn/MSqAy

Catalog

• background

• accident

• analysis

• summary

• Tool sharing

background

When we use the amount to calculate or display the amount, we often use BigDecimal, It is also a very recommended type when it comes to the amount .

BigDecimal It also provides many constructor methods , Improper use of these constructor methods may cause unnecessary trouble or even loss of money , Thus causing accident asset loss .

accident

Next, let's look at an accident at the cashier .

| Problem description

The cashier reported an error in calculating the amount of goods , The order cannot be paid .

| Accident level

P0

| Accident process

as follows ：

• 13:44, Get the alarm , Order payment failed , Payment availability reduced to 60%

• 13:50, Quickly roll back online code , Back to normal

• 14:20,review Code , Problems found in pre release verification

• 14:58, Modify the problem code to go online , Online recovery

| The cause of the problem

BigDecimal Lost precision in amount calculation .

Cause analysis

First, let's use a piece of code to reproduce the root cause of the problem , As shown below ：

public static void main(String[] args) {
    BigDecimal bigDecimal=new BigDecimal(88);
    System.out.println(bigDecimal);
    bigDecimal=new BigDecimal("8.8");
    System.out.println(bigDecimal);
    bigDecimal=new BigDecimal(8.8);
    System.out.println(bigDecimal);
}

The results are as follows ：

Found by test , When using double perhaps float These floating-point data types , Will lose precision ,String、int Will not be , Why is that ？

Let's open the constructor method to see the source code ：

public static long doubleToLongBits(double value) {
    long result = doubleToRawLongBits(value);
    // Check for NaN based on values of bit fields, maximum
    // exponent and nonzero significand.
    if ( ((result & DoubleConsts.EXP_BIT_MASK) ==
          DoubleConsts.EXP_BIT_MASK) &&
         (result & DoubleConsts.SIGNIF_BIT_MASK) != 0L)
        result = 0x7ff8000000000000L;
    return result;
}

The problem is doubleToRawLongBits In this way , stay jdk in double class （float And int Corresponding ） Provided in double And long transformation ,doubleToRawLongBits Will be double Convert to long, This method is the original method （ The bottom is not java Realization , yes c++ Realized ）.

double The reason why something goes wrong , It's because the decimal point to binary lost precision .

BigDecimal Expand decimal number in processing N Times make it count on integers , And keep the corresponding precision information .

①float and double type , It is mainly designed for scientific calculation and engineering calculation , The reason for performing binary floating-point operations , It is designed to provide accurate and fast approximate sum calculation over a wide range of numerical values .

② It doesn't provide completely accurate results , So it should not be used for precise results .

③ When the floating-point number reaches a certain large number , Will automatically use scientific counting , Such a representation is only approximate to the real number but not equal to the real number .

④ When decimals are converted to binary, there will be infinite cycles or the length of the floating-point mantissa will be exceeded .

summary

therefore , In the process of precision calculation , We try to use String Type to convert .

Last , Recommend a planet of my knowledge , Join now , front 100 name , It only needs  25 element that will do , Very favorable .