Do you dare to use BigDecimal without mastering these pits?

background

Has been engaged in financial related projects , So for BigDecimal I can't be more familiar with , I have also seen many students because they don't know 、 Failure to understand or improper use leads to asset loss events .

therefore , If you are engaged in financial related projects , Or your project involves the calculation of the amount , Then you must take the time to read this article , Study comprehensively BigDecimal.

BigDecimal summary

Java stay java.math Provided in the package API class BigDecimal, Used for more than 16 The number of significant bits of a bit is calculated precisely . Double precision floating point variables double Can handle 16 Bit significant number , But in practice , It may be necessary to calculate and process larger or smaller numbers .

In general , For figures that do not require accurate calculation accuracy , You can use it directly Float and Double Handle , however Double.valueOf(String)  and Float.valueOf(String) Will lose precision . So if you need accurate results , Must be used BigDecimal Class .

BigDecimal Object provides traditional +、-、*、/ Methods corresponding to arithmetic operators , Carry out corresponding operations through these methods .BigDecimal It's all immutable （immutable） Of ,  In every four operations , A new object is created  , So when doing addition, subtraction, multiplication and division, remember to save the value after operation .

BigDecimal Of 4 Pit

In the use of BigDecimal when , Yes 4 A pit in a usage scenario , You have to know , If not used properly , It must be miserable . Master these cases , When others write code with holes , You can also recognize it at a glance , Daniel is trained in this way .

First of all ： Floating point type pit

Learning to understand BigDecimal Before the pit , Let's start with an old-fashioned question ： If you use Float、Double When calculating with floating-point type , It is possible to get an approximate value , Not the exact value .

Consider the following code ：

 @Test
 public void test0(){
 float a = 1;
 float b = 0.9f;
 System.out.println(a - b);
 }
Copy code

What's the result ？0.1 Do you ？ No , The result of executing the above code is 0.100000024. The reason for this result , Because 0.1 The binary representation of is infinite loop .

Because computer resources are limited , So there is no way to express it accurately in binary  0.1, Only use 「 Approximate value 」 To express , With limited accuracy , Maximize proximity to  0.1  Binary number of , This will result in a lack of accuracy

.

We all know about the above phenomenon , No more details . meanwhile , It is also concluded that floating-point types can be considered in scientific counting , But if it involves the amount calculation, we should use BigDecimal To calculate .

that ,BigDecimal Is it certain to avoid the above floating point problem ？ Take a look at the following example ：

 @Test
 public void test1(){
 BigDecimal a = new BigDecimal(0.01);
 BigDecimal b = BigDecimal.valueOf(0.01);
 System.out.println("a = " + a);
 System.out.println("b = " + b);
 }
Copy code

The code in the above unit test ,a and b What are the results ？

a = 0.01000000000000000020816681711721685132943093776702880859375
b = 0.01
Copy code

Example above , Even with BigDecimal, As a result, there will still be accuracy problems . This involves creating BigDecimal Object time , If there is an initial value , Is to use new BigDecimal In the form of , Or through BigDecimal#valueOf The method .

The reason why the above phenomenon occurs , Because new BigDecimal when , Incoming 0.1 It is already a floating-point type , Since the above value is only approximate , In the use of new BigDecimal This approximation is completely preserved .

and BigDecimal#valueOf Is different , Its source code implementation is as follows ：

   public static BigDecimal valueOf(double val) {
       // Reminder: a zero double returns '0.0', so we cannot fastpath
       // to use the constant ZERO. This might be important enough to
       // justify a factory approach, a cache, or a few private
       // constants, later.
       return new BigDecimal(Double.toString(val));
   }
Copy code

stay valueOf Inside , Use Double#toString Method , Convert the value of floating-point type to string , Therefore, there is no problem of accuracy loss .

At this point, we draw a basic conclusion ：

First of all , In the use of BigDecimal Constructor , Try to pass strings instead of floating-point types ; second , If you can't meet the first , You can use BigDecimal#valueOf Method to construct the initialization value

.

Let's extend it here ,BigDecimal Common construction methods are as follows ：

BigDecimal(int)        Create an object with the integer value specified by the parameter .
BigDecimal(double)    Create an object with the double value specified by the parameter .
BigDecimal(long)      Create an object with the long integer value specified by the parameter .
BigDecimal(String)    Create an object with a string value specified by the parameter .
Copy code

The parameter type involved is double Construction method of , There will be the above problems , Pay special attention when using .

second ： Pit of floating-point precision

If you compare two BigDecimal Is the value of equal , How would you compare ？ Use equals The method is still compareTo Methods? ？

Let's start with an example ：

 @Test
 public void test2(){
 BigDecimal a = new BigDecimal("0.01");
 BigDecimal b = new BigDecimal("0.010");
 System.out.println(a.equals(b));
 System.out.println(a.compareTo(b));
 }
Copy code

At first glance, it may feel the same , But in fact, their essence is not the same .

equals The method is based on BigDecimal Realized equals Method to compare , Intuitive impression is to compare whether two objects are the same , So how is the code implemented ？

   @Override
   public boolean equals(Object x) {
       if (!(x instanceof BigDecimal))
           return false;
       BigDecimal xDec = (BigDecimal) x;
       if (x == this)
           return true;
       if (scale != xDec.scale)
           return false;
       long s = this.intCompact;
       long xs = xDec.intCompact;
       if (s != INFLATED) {
           if (xs == INFLATED)
               xs = compactValFor(xDec.intVal);
           return xs == s;
       } else if (xs != INFLATED)
           return xs == compactValFor(this.intVal);
​
       return this.inflated().equals(xDec.inflated());
   }
Copy code

Read the code carefully and you can see ,equals Method not only compares whether the values are equal , The accuracy is also compared . In the above example , Because the accuracy of the two is different , therefore equals The result of the method is of course false 了 . and compareTo Method implemented Comparable Interface , The real comparison is the size of the value , The returned value is -1（ Less than ）,0（ be equal to ）,1（ Greater than ）.

Basic conclusion ：

General situation , If you compare two BigDecimal Value size , With its implementation compareTo Method ; If the comparison of accuracy is strictly limited , Then consider using equals Method

.

in addition , This kind of scene is comparing 0 Values are common , For example, comparison BigDecimal("0")、BigDecimal("0.0")、BigDecimal("0.00"), Be sure to use compareTo Methods for comparison .

Third ： Set the accuracy of the pit

In the project, I saw many students pass BigDecimal The accuracy and rounding mode of the calculation results are not set during calculation , It's really anxious , Although in most cases, nothing will happen . But the following scenes are not necessarily ：

 @Test
 public void test3(){
 BigDecimal a = new BigDecimal("1.0");
 BigDecimal b = new BigDecimal("3.0");
 a.divide(b);
 }
Copy code

What is the result of executing the above code ？

ArithmeticException abnormal

！

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
​
 at java.math.BigDecimal.divide(BigDecimal.java:1690)
 ...
Copy code

The occurrence of this exception is also explained in the official documents ：

If the quotient has a nonterminating decimal expansion and the operation is specified to return an exact result, an ArithmeticException is thrown. Otherwise, the exact result of the division is returned, as done for other operations.

So in summary , If you are dividing （divide） During the operation , If the quotient is an infinite decimal （0.333…）, The result of the operation is expected to be an accurate number , Then it will throw

ArithmeticException

abnormal .

here , Just use divide Method, you can specify the precision of the result ：

 @Test
 public void test3(){
 BigDecimal a = new BigDecimal("1.0");
 BigDecimal b = new BigDecimal("3.0");
 BigDecimal c = a.divide(b, 2,RoundingMode.HALF_UP);
 System.out.println(c);
 }
Copy code

Execute the above code , The input result is 0.33.

Basic conclusion ：

In the use of BigDecimal Conduct （ all ） Operation time , Be sure to specify the precision and rounding mode clearly

.

Expand the , The rounding pattern is defined in RoundingMode Enumeration class , share 8 Kind of ：

• RoundingMode.UP： Rounding away from zero . Always increase the number before discarding the non-zero part ( Always add... To the number in front of the non-zero discard part 1). Be careful , This rounding mode never reduces the size of the calculated value .

• RoundingMode.DOWN： Rounding mode close to zero . Never increase the number before discarding a part ( Never give up the number in front of the part plus 1, That is, cut it short ). Be careful , This rounding mode never increases the size of the calculated value .

• RoundingMode.CEILING： A rounding pattern close to positive infinity . If  BigDecimal  Being positive , Then the behavior and  ROUNDUP  identical ; If a negative , Then the behavior and  ROUNDDOWN  identical . Be careful , This rounding mode never reduces the calculated value .

• RoundingMode.FLOOR： A rounding pattern close to negative infinity . If  BigDecimal  Being positive , Then the behavior and  ROUNDDOWN  identical ; If a negative , Then the behavior and  ROUNDUP  identical . Be careful , This rounding mode never increases the calculated value .

• RoundingMode.HALF_UP： towards “ The closest ” Round off the numbers , If the distance from two adjacent numbers is equal , It is the rounding mode of rounding up . If you give up part  >= 0.5, Then the behavior and  ROUND_UP  identical ; Otherwise, the behavior and  ROUND_DOWN  identical . Be careful , This is the rounding pattern we learned in primary school ( rounding ).

• RoundingMode.HALF_DOWN： towards “ The closest ” Round off the numbers , If the distance from two adjacent numbers is equal , Is the rounding mode of rounding up . If you give up part  > 0.5, Then the behavior and  ROUND_UP  identical ; Otherwise, the behavior and  ROUND_DOWN  identical ( Round to the nearest ).

• RoundingMode.HALF_EVEN： towards “ The closest ” Round off the numbers , If the distance from two adjacent numbers is equal , Round to the adjacent even number . If the number to the left of the discarded part is odd , Then the behavior and  ROUNDHALFUP  identical ; If it's an even number , Then the behavior and  ROUNDHALF_DOWN  identical . Be careful , When repeating a series of calculations , This rounding mode minimizes the cumulative error . This rounding mode is also known as “ Banker's Rounding ”, Mainly used in the United States . Round to the nearest , In two fifths . If the previous one is odd , Then enter , Otherwise, give up . The following example is to keep the decimal point 1 position , So the result of this rounding .1.15 ==> 1.2 ,1.25 ==> 1.2

• RoundingMode.UNNECESSARY： Assert that the requested operation has exact results , So no rounding is required . If this rounding mode is specified for the operation to get accurate results , Throw out ArithmeticException.

Usually, we use rounding, that is RoundingMode.HALF_UP.

Fourth ： Three kinds of string output pits

When using BigDecimal after , Need to be converted to String type , How do you operate ？ direct toString？

Let's take a look at the following code ：

@Test
public void test4(){
 BigDecimal a = BigDecimal.valueOf(35634535255456719.22345634534124578902);
 System.out.println(a.toString());
}
Copy code

Is the result of execution the corresponding value above ？ Not at all ：

3.563453525545672E+16
Copy code

in other words , I originally wanted to print strings , The result is the value of scientific counting .

Here we need to understand BigDecimal Three ways to convert strings

• toPlainString()： Don't use any scientific counting ;

• toString()： Use scientific counting when necessary ;

• toEngineeringString() ： Use engineering counting when necessary . It's similar to scientific counting , It's just that the powers of the exponents are 3 Multiple , This is convenient for engineering applications , Because in many unit conversions it's 10^3;

Examples of the results of the three methods are as follows ：

Basic conclusion ：

The display format is different according to the data results , Use different string output methods , The commonly used methods are toPlainString()

 .

in addition ,NumberFormat Class format() Methods can be used BigDecimal Object as its parameter , You can use BigDecimal To exceed 16 The currency value of a significant number , Percentage value , As well as general numerical value for formatting control .

An example is as follows ：

NumberFormat currency = NumberFormat.getCurrencyInstance(); // Create currency formatting references
NumberFormat percent = NumberFormat.getPercentInstance(); // Create percentage formatting references
percent.setMaximumFractionDigits(3); // Percentages have the most decimal points 3 position
​
BigDecimal loanAmount = new BigDecimal("15000.48"); // amount of money
BigDecimal interestRate = new BigDecimal("0.008"); // The interest rate
BigDecimal interest = loanAmount.multiply(interestRate); // Multiply
​
System.out.println(" amount of money :\t" + currency.format(loanAmount));
System.out.println(" The interest rate :\t" + percent.format(interestRate));
System.out.println(" interest :\t" + currency.format(interest));
Copy code

The output is as follows ：

amount of money : ￥15,000.48 
The interest rate : 0.8% 
interest : ￥120.00
Copy code

Summary

This article introduces BigDecimal The pit of the scene in use , And based on these pits, we get “ Best practices ”. Although it is recommended to use in some scenarios BigDecimal, It can achieve better accuracy , But compared with double and float, There is still a certain loss , Especially in dealing with huge , It's especially obvious when it comes to complex operations . Therefore, it is unnecessary to use the general accuracy calculation BigDecimal. When it must be used , Be sure to avoid the above pit .