logo

BigDecimal除法的精度問題

在使用BigDecimal的除法時(shí)，遇到一個(gè)鬼畜的問題，本以為的精度計(jì)算，結(jié)果使用返回0，當(dāng)然最終發(fā)現(xiàn)還是自己的使用姿勢不對導(dǎo)致的，因此記錄一下，避免后面重蹈覆轍

I. 問題拋出

在使用BigDecimal做高精度的除法時(shí)，一不注意遇到了一個(gè)小問題，如下

@Test
public void testBigDecimal() {
    BigDecimal origin = new BigDecimal(541253);
    BigDecimal now = new BigDecimal(12389431);

    BigDecimal val = origin.divide(now, RoundingMode.HALF_UP);
    System.out.println(val);

    origin = new BigDecimal(541253);
    now = new BigDecimal(12389431.3);
    val = origin.divide(now, RoundingMode.HALF_UP);
    System.out.println(val);

    origin = new BigDecimal(541253.4);
    now = new BigDecimal(12389431);
    val = origin.divide(now, RoundingMode.HALF_UP);
    System.out.println(val);
}

上面的輸出是什么 ？

0
0
0.043686703610520937021487456961257

為什么前面兩個(gè)會(huì)是0呢，如果直接是 541253 / 12389431 = 0 倒是可以理解, 但是BigDecimal不是高精度的計(jì)算么，講道理不應(yīng)該不會(huì)出現(xiàn)這種整除的問題吧

我們知道在BigDecimal做觸發(fā)時(shí)，可以指定保留小數(shù)的參數(shù)，如果加上這個(gè)，是否會(huì)不一樣呢？

BigDecimal origin = new BigDecimal(541253);
BigDecimal now = new BigDecimal(12389431);

BigDecimal val = origin.divide(now, 5, RoundingMode.HALF_UP);
System.out.println(val);

輸出結(jié)果為:

0.04369

所以說在指定了保留小數(shù)之后，則沒有問題，所以大膽的猜測一下，是不是上面的幾種case中，由于scale值沒有指定時(shí)，默認(rèn)值不一樣，從而導(dǎo)致最終結(jié)果的精度不同呢？

簡單的深入源碼分析一下，執(zhí)行的方式為 origin.divide(now, RoundingMode.HALF_UP);, 所以這個(gè)scale參數(shù)就瞄準(zhǔn)origin對象，而這個(gè)對象，就只能去分析它的構(gòu)造了，因?yàn)闆]有其他的地方使用

II. 源碼定位

1. 整形傳參構(gòu)造

分析下面這一行， 直接進(jìn)入源碼

BigDecimal origin = new BigDecimal(541253);

很明顯的int傳參構(gòu)造，進(jìn)去簡單看一下

// java.math.BigDecimal#BigDecimal(int)
public BigDecimal(int val) {
    this.intCompact = val;
    this.scale = 0;
    this.intVal = null;
}

public BigDecimal(long val) {
    this.intCompact = val;
    this.intVal = (val == INFLATED) ? INFLATED_BIGINT : null;
    this.scale = 0;
}

so，很明確的知道默認(rèn)的scale為0，也就是說當(dāng)origin為正數(shù)時(shí)，以它進(jìn)行的除法，不現(xiàn)實(shí)指定scale參數(shù)時(shí)，最終返回的都是沒有小數(shù)的，同樣看一眼，還有l(wèi)ong的傳參方式， BigInteger也一樣

2. 浮點(diǎn)傳參

接下來就是浮點(diǎn)的scale默認(rèn)值確認(rèn)了，這個(gè)構(gòu)造相比前面的復(fù)雜一點(diǎn)，源碼就不貼了，太長，也看不太懂做了些啥，直接用猥瑣一點(diǎn)的方式，進(jìn)入debug模式，單步執(zhí)行

@Test
public void testBigDecimal() {
    BigDecimal origin = new BigDecimal(541253.0);
    BigDecimal now = new BigDecimal(12389431.1);
    BigDecimal tmp = new BigDecimal(0.0);
}

根據(jù)debug的結(jié)果，第一個(gè)，scale為0； 第二個(gè)scale為29, 第三個(gè)scale為0

origin

now

tmp

3. String傳參

依然是一大串的邏輯，同樣采用單步debug的方式試下

@Test
public void testBigDecimal() {
    BigDecimal origin = new BigDecimal("541253.0");
    BigDecimal now = new BigDecimal("12389431.1");
    BigDecimal t = new BigDecimal("0.0");
}

上面三個(gè)的scale都是1

smaple

4. 小結(jié)

• 對于BigDecimal進(jìn)行除法運(yùn)算時(shí)，最好指定其scale參數(shù)，不然可能會(huì)有坑
• 對于BigDecimla的scale初始化的原理，有待深入看下BigDecimal是怎么實(shí)現(xiàn)的

最后貼一張乘法的圖作為收尾

mul

II. 其他

1. 一灰灰Blog： https://liuyueyi.github.io/hexblog

一灰灰的個(gè)人博客，記錄所有學(xué)習(xí)和工作中的博文，歡迎大家前去逛逛

2. 聲明

盡信書則不如，已上內(nèi)容，純屬一家之言，因個(gè)人能力有限，難免有疏漏和錯(cuò)誤之處，如發(fā)現(xiàn)bug或者有更好的建議，歡迎批評指正，不吝感激

• 微博地址: 小灰灰Blog
• QQ： 一灰灰/3302797840

3. 掃描關(guān)注

QrCode