[[428479]]

本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲Tang。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。

眾所周知阿里巴巴開(kāi)發(fā)手冊(cè)里面有一條強(qiáng)制的規(guī)則，說(shuō)的是在包裝類對(duì)象之間的值比較的時(shí)候需要使用 equals 方法，在 -128 和 127 之間的數(shù)值比較可以使用 ==，如下圖所示。具體的原因相信大家都知道，雖然規(guī)則中提到 -128 和 127 之間的數(shù)值比較可以使用 ==，但是阿粉強(qiáng)烈建議你還是不要這樣，包裝類統(tǒng)一使用 equals，特別是如果有些數(shù)值是通過(guò) API 或者 RPC 接口過(guò)來(lái)的，一定要注意。

我們看看下面的程序

public class IntegerEqualTest { 
 
    public static void main(String[] args) { 
 
        Integer a = genA(); 
        //Integer a = genB(); 
        Integer b = 0; 
        if (a == b) { 
            System.out.println("a == 0"); 
        } else { 
            System.out.println("a != 0"); 
        } 
        System.out.println(a == b); 
        System.out.println(a == 0); 
    } 
 
    private static Integer genA() { 
        return new Integer(0); 
    } 
 
    private static Integer genB() { 
        return 0; 
    } 
} 

大家可以先看下上面這一段代碼，先猜測(cè)一下運(yùn)行的結(jié)果是什么，如果再把 Integer a = genA(); 這行注釋，Integer a = genB(); 這行放開(kāi)，運(yùn)行的結(jié)果又是什么。

好，1 2 3 結(jié)果如下所示

當(dāng)我們替換注釋那一行的時(shí)候，運(yùn)行結(jié)果如下

看到這里其實(shí)很多小伙伴都知道是為什么，因?yàn)?genA() 方法里面是使用的 Integer 的構(gòu)造器，構(gòu)造的是一個(gè)新的對(duì)象，所以在使用 == 做對(duì)比的時(shí)候，比較的兩個(gè)對(duì)象是不一樣的。

是的，原因是這個(gè)，但是還有一點(diǎn)沒(méi)說(shuō)清楚那就是為什么在使用 genA() 的時(shí)候，下面的結(jié)果會(huì)不一樣。

System.out.println(a == b);//false 
 System.out.println(a == 0);//true 

其實(shí)短短的幾行代碼里面，包含了好幾個(gè)知識(shí)點(diǎn)，分別是自動(dòng)裝箱拆箱以及 Integer 的 -128 到 127 的數(shù)字緩存。

裝箱拆箱

裝箱：自動(dòng)將基本數(shù)據(jù)類型轉(zhuǎn)換為包裝器類型;

拆箱：就是自動(dòng)將包裝器類型轉(zhuǎn)換為基本數(shù)據(jù)類型。

在裝箱的時(shí)候自動(dòng)調(diào)用的是 Integer 的 valueOf(int) 方法。而在拆箱的時(shí)候自動(dòng)調(diào)用的是 Integer 的 intValue方法。

上面的代碼中 Integer b = 0; 會(huì)觸發(fā)自動(dòng)的裝箱調(diào)用 Integer valueOf() 方法。而在使用 a == 0 這句的時(shí)候，會(huì)觸發(fā)自動(dòng)的拆箱。然后我們看源碼會(huì)發(fā)現(xiàn)有下面緩存的邏輯，其中 IntegerCache.low 是 -128，IntegerCache.high 默認(rèn)是 127，不過(guò)可以通過(guò) JVM 參數(shù)進(jìn)行配置。我們這里的代碼是 0，所以會(huì)從緩存中獲取。

public static Integer valueOf(int i) { 
    if (i >= IntegerCache.low && i <= IntegerCache.high) 
        return IntegerCache.cache[i + (-IntegerCache.low)]; 
    return new Integer(i); 
} 

為了充分說(shuō)明 Integer 的緩存，我們看下下面這段程序的執(zhí)行結(jié)果

Integer c1 = 128; 
Integer c2 = 128; 
System.out.println(c1 == c2); 

在運(yùn)行之前我們先自己分析一下，首先 Integer c1 = 128 和 Integer c2 = 128 按照我們上面說(shuō)的，會(huì)觸發(fā)自動(dòng)裝箱調(diào)用 valueOf 方法，通過(guò) valueOf源碼我們可以看到在默認(rèn)的情況下 128 已經(jīng)不再 Integer 的緩存里面了，所以 if 條件不滿足會(huì)通過(guò) new Integer 構(gòu)造方法創(chuàng)建兩個(gè)對(duì)象，所以最終的結(jié)果應(yīng)該是輸出 false。

下面再說(shuō)一下為什么說(shuō)在 -128 和 127 以內(nèi)的也不建議直接使用 == 來(lái)實(shí)現(xiàn)比較，很顯然就跟我們上面的genA() 方法一樣，很多時(shí)候不會(huì)一下子就知道一個(gè)方法值是怎么得到，即使是緩存范圍以內(nèi)，別人也有可能是通過(guò)構(gòu)造函數(shù)創(chuàng)建出來(lái)的，這樣我們?cè)谧霰容^的時(shí)候很有可能就會(huì)跟預(yù)期的不一樣，從而產(chǎn)生事故。

特別是如果通過(guò) RPC 接口獲得返回結(jié)果，我們可能連別人的實(shí)現(xiàn)方式壓根就看不到，更沒(méi)辦法提前知道了。所以我們還是老老實(shí)實(shí)的按照阿里巴巴的 Java 規(guī)范來(lái)編寫(xiě)代碼，采用equals 方法來(lái)判斷，這樣肯定沒(méi)問(wèn)題。