詳解為什么阿里巴巴禁止使用BigDecimal的equals方法做等值比較
BigDecimal,相信對(duì)于很多人來(lái)說(shuō)都不陌生,很多人都知道他的用法,這是一種java.math包中提供的一種可以用來(lái)進(jìn)行精確運(yùn)算的類型。
很多人都知道,在進(jìn)行金額表示、金額計(jì)算等場(chǎng)景,不能使用double、float等類型,而是要使用對(duì)精度支持的更好的BigDecimal。
所以,很多支付、電商、金融等業(yè)務(wù)中,BigDecimal的使用非常頻繁。而且不得不說(shuō)這是一個(gè)非常好用的類,其內(nèi)部自帶了很多方法,如加,減,乘,除等運(yùn)算方法都是可以直接調(diào)用的。
除了需要用BigDecimal表示數(shù)字和進(jìn)行數(shù)字運(yùn)算以外,代碼中還經(jīng)常需要對(duì)于數(shù)字進(jìn)行相等判斷。
關(guān)于這個(gè)知識(shí)點(diǎn),在最新版的《阿里巴巴Java開(kāi)發(fā)手冊(cè)》中也有說(shuō)明:

這背后的思考是什么呢?
我在之前的CodeReview中,看到過(guò)以下這樣的低級(jí)錯(cuò)誤:
if(bigDecimal == bigDecimal1){
// 兩個(gè)數(shù)相等
}
這種錯(cuò)誤,相信聰明的讀者一眼就可以看出問(wèn)題,因?yàn)锽igDecimal是對(duì)象,所以不能用==來(lái)判斷兩個(gè)數(shù)字的值是否相等。
以上這種問(wèn)題,在有一定的經(jīng)驗(yàn)之后,還是可以避免的,但是聰明的讀者,看一下以下這行代碼,你覺(jué)得他有問(wèn)題嗎:
if(bigDecimal.equals(bigDecimal1)){
// 兩個(gè)數(shù)相等
}
可以明確的告訴大家,以上這種寫法,可能得到的結(jié)果和你預(yù)想的不一樣!
先來(lái)做個(gè)實(shí)驗(yàn),運(yùn)行以下代碼:
BigDecimal bigDecimal = new BigDecimal(1);
BigDecimal bigDecimal1 = new BigDecimal(1);
System.out.println(bigDecimal.equals(bigDecimal1));
BigDecimal bigDecimal2 = new BigDecimal(1);
BigDecimal bigDecimal3 = new BigDecimal(1.0);
System.out.println(bigDecimal2.equals(bigDecimal3));
BigDecimal bigDecimal4 = new BigDecimal("1");
BigDecimal bigDecimal5 = new BigDecimal("1.0");
System.out.println(bigDecimal4.equals(bigDecimal5));
以上代碼,輸出結(jié)果為:
true
true
false
BigDecimal的equals原理
通過(guò)以上代碼示例,我們發(fā)現(xiàn),在使用BigDecimal的equals方法對(duì)1和1.0進(jìn)行比較的時(shí)候,有的時(shí)候是true(當(dāng)使用int、double定義BigDecimal時(shí)),有的時(shí)候是false(當(dāng)使用String定義BigDecimal時(shí))。
那么,為什么會(huì)出現(xiàn)這樣的情況呢,我們先來(lái)看下BigDecimal的equals方法。
在BigDecimal的JavaDoc中其實(shí)已經(jīng)解釋了其中原因:
Compares this BigDecimal with the specified Object for equality. Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method)
大概意思就是,equals方法和compareTo并不一樣,equals方法會(huì)比較兩部分內(nèi)容,分別是值(value)和精度(scale)
對(duì)應(yīng)的代碼如下:

所以,我們以上代碼定義出來(lái)的兩個(gè)BigDecimal對(duì)象(bigDecimal4和bigDecimal5)的精度是不一樣的,所以使用equals比較的結(jié)果就是false了。
嘗試著對(duì)代碼進(jìn)行debug,在debug的過(guò)程中我們也可以看到bigDecimal4的精度時(shí)0,而bigDecimal5的精度是1。

到這里,我們大概解釋清楚了,之所以equals比較bigDecimal4和bigDecimal5的結(jié)果是false,是因?yàn)榫炔煌?/p>
那么,為什么精度不同呢?為什么bigDecimal2和bigDecimal3的精度是一樣的(當(dāng)使用int、double定義BigDecimal時(shí)),而bigDecimal4和bigDecimal5卻不一樣(當(dāng)使用String定義BigDecimal時(shí))呢?
為什么精度不同
這個(gè)就涉及到BigDecimal的精度問(wèn)題了,這個(gè)問(wèn)題其實(shí)是比較復(fù)雜的,由于不是本文的重點(diǎn),這里面就簡(jiǎn)單介紹一下吧。大家感興趣的話,后面單獨(dú)講。
首先,BigDecimal一共有以下4個(gè)構(gòu)造方法:
BigDecimal(int) BigDecimal(double) BigDecimal(long) BigDecimal(String)
以上四個(gè)方法,創(chuàng)建出來(lái)的的BigDecimal的精度是不同的。
BigDecimal(long) 和BigDecimal(int)
首先,最簡(jiǎn)單的就是BigDecimal(long) 和BigDecimal(int),因?yàn)槭钦麛?shù),所以精度就是0 :
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;
}
BigDecimal(double)
而對(duì)于BigDecimal(double) ,當(dāng)我們使用new BigDecimal(0.1)創(chuàng)建一個(gè)BigDecimal 的時(shí)候,其實(shí)創(chuàng)建出來(lái)的值并不是整好等于0.1的,而是0.1000000000000000055511151231257827021181583404541015625 。這是因?yàn)閐oule自身表示的只是一個(gè)近似值。
那么,無(wú)論我們使用new BigDecimal(0.1)還是new BigDecimal(0.10)定義,他的近似值都是0.1000000000000000055511151231257827021181583404541015625這個(gè),那么他的精度就是這個(gè)數(shù)字的位數(shù),即55。

其他的浮點(diǎn)數(shù)也同樣的道理。對(duì)于new BigDecimal(1.0)這樣的形式來(lái)說(shuō),因?yàn)樗举|(zhì)上也是個(gè)整數(shù),所以他創(chuàng)建出來(lái)的數(shù)字的精度就是0。
所以,因?yàn)锽igDecimal(1.0)和BigDecimal(1.00)的精度是一樣的,所以在使用equals方法比較的時(shí)候,得到的結(jié)果就是true。
BigDecimal(string)
而對(duì)于BigDecimal(double) ,當(dāng)我們使用new BigDecimal(“0.1”)創(chuàng)建一個(gè)BigDecimal 的時(shí)候,其實(shí)創(chuàng)建出來(lái)的值正好就是等于0.1的。那么他的精度也就是1。
如果使用new BigDecimal(“0.10000”),那么創(chuàng)建出來(lái)的數(shù)就是0.10000,精度也就是5。
所以,因?yàn)锽igDecimal(“1.0”)和BigDecimal(“1.00”)的精度不一樣,所以在使用equals方法比較的時(shí)候,得到的結(jié)果就是false。
如何比較BigDecimal
前面,我們解釋了BigDecimal的equals方法,其實(shí)不只是會(huì)比較數(shù)字的值,還會(huì)對(duì)其精度進(jìn)行比較。
所以,當(dāng)我們使用equals方法判斷判斷兩個(gè)數(shù)是否相等的時(shí)候,是極其嚴(yán)格的。
那么,如果我們只想判斷兩個(gè)BigDecimal的值是否相等,那么該如何判斷呢?
BigDecimal中提供了compareTo方法,這個(gè)方法就可以只比較兩個(gè)數(shù)字的值,如果兩個(gè)數(shù)相等,則返回0。
BigDecimal bigDecimal4 = new BigDecimal("1");
BigDecimal bigDecimal5 = new BigDecimal("1.0000");
System.out.println(bigDecimal4.compareTo(bigDecimal5));
以上代碼,輸出結(jié)果:
0
其源碼如下:

總結(jié)
BigDecimal是一個(gè)非常好用的表示高精度數(shù)字的類,其中提供了很多豐富的方法。
但是,他的equals方法使用的時(shí)候需要謹(jǐn)慎,因?yàn)樗诒容^的時(shí)候,不僅比較兩個(gè)數(shù)字的值,還會(huì)比較他們的精度,只要這兩個(gè)因素有一個(gè)是不相等的,那么結(jié)果也是false、
如果讀者想要對(duì)兩個(gè)BigDecimal的數(shù)值進(jìn)行比較的話,可以使用compareTo方法。
到此這篇關(guān)于詳解為什么阿里巴巴禁止使用BigDecimal的equals方法做等值比較的文章就介紹到這了,更多相關(guān)禁止BigDecimal equals方法等值內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
SpringCloud使用Kafka Streams實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理
使用Kafka Streams在Spring Cloud中實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理可以幫助我們構(gòu)建可擴(kuò)展、高性能的實(shí)時(shí)數(shù)據(jù)處理應(yīng)用,Kafka Streams是一個(gè)基于Kafka的流處理庫(kù),本文介紹了如何在SpringCloud中使用Kafka Streams實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理,需要的朋友可以參考下2024-07-07
Java中List與數(shù)組相互轉(zhuǎn)換實(shí)例分析
這篇文章主要介紹了Java中List與數(shù)組相互轉(zhuǎn)換的方法,實(shí)例分析了Java中List與數(shù)組相互轉(zhuǎn)換中容易出現(xiàn)的問(wèn)題與相關(guān)的解決方法,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2015-05-05
java阻塞隊(duì)列實(shí)現(xiàn)原理及實(shí)例解析
這篇文章主要介紹了java阻塞隊(duì)列實(shí)現(xiàn)原理及實(shí)例解析,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2019-11-11
Java前端Layer.open.btn驗(yàn)證無(wú)效解決方法
在本篇文章里我們給大家整理了一篇關(guān)于Java前端Layer.open.btn驗(yàn)證無(wú)效解決方法以及實(shí)例代碼,需要的朋友們可以參考學(xué)習(xí)下。2019-09-09
SpringBoot集成Tess4J實(shí)現(xiàn)OCR的示例代碼
Tess4J是一個(gè)基于Tesseract OCR引擎的Java接口,可以用來(lái)識(shí)別圖像中的文本,說(shuō)白了,就是封裝了它的API,讓Java可以直接調(diào)用,本文給大家介紹了SpringBoot集成Tess4J實(shí)現(xiàn)OCR的示例,需要的朋友可以參考下2024-12-12
Java編程實(shí)現(xiàn)中英混合字符串?dāng)?shù)組按首字母排序的方法
這篇文章主要介紹了Java編程實(shí)現(xiàn)中英混合字符串?dāng)?shù)組按首字母排序的方法,涉及Java字符串操作及拼音轉(zhuǎn)換的相關(guān)使用技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下2015-11-11

