為什麼說兩個 Integer 數值之間不建議使用“==”進行比較

眾所周知阿里巴巴開發手冊裡面有一條強制的規則，說的是在包裝類物件之間的值比較的時候需要使用 equals 方法，在 -128 和 127 之間的數值比較可以使用 ==，如下圖所示。具體的原因相信大家都知道，雖然規則中提到 -128 和 127 之間的數值比較可以使用 ==，但是阿粉強烈建議你還是不要這樣，包裝類統一使用 equals，特別是如果有些數值是透過 API 或者 RPC 介面過來的，一定要注意。

我們看看下面的程式

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;
    }
}

大家可以先看下上面這一段程式碼，先猜測一下執行的結果是什麼，如果再把 Integer a = genA(); 這行註釋，Integer a = genB(); 這行放開，執行的結果又是什麼。

好，1 2 3 結果如下所示

當我們替換註釋那一行的時候，執行結果如下

看到這裡其實很多小夥伴都知道是為什麼，因為 genA() 方法裡面是使用的 Integer 的構造器，構造的是一個新的物件，所以在使用 == 做對比的時候，比較的兩個物件是不一樣的。

是的，原因是這個，但是還有一點沒說清楚那就是為什麼在使用 genA() 的時候，下面的結果會不一樣。

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

其實短短的幾行程式碼裡面，包含了好幾個知識點，分別是自動裝箱拆箱以及 Integer 的 -128 到 127 的數字快取。

裝箱拆箱

裝箱：自動將基本資料型別轉換為包裝器型別；

拆箱：就是自動將包裝器型別轉換為基本資料型別。

在裝箱的時候自動呼叫的是 Integer 的 valueOf(int) 方法。而在拆箱的時候自動呼叫的是 Integer 的 intValue方法。

上面的程式碼中 Integer b = 0; 會觸發自動的裝箱呼叫 Integer valueOf() 方法。而在使用 a == 0 這句的時候，會觸發自動的拆箱。然後我們看原始碼會發現有下面快取的邏輯，其中 IntegerCache.low 是 -128，IntegerCache.high 預設是 127，不過可以透過 JVM 引數進行配置。我們這裡的程式碼是 0，所以會從快取中獲取。

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

為了充分說明 Integer 的快取，我們看下下面這段程式的執行結果

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

在執行之前我們先自己分析一下，首先 Integer c1 = 128 和 Integer c2 = 128 按照我們上面說的，會觸發自動裝箱呼叫 valueOf 方法，透過 valueOf原始碼我們可以看到在預設的情況下 128 已經不再 Integer 的快取裡面了，所以 if 條件不滿足會透過 new Integer 構造方法建立兩個物件，所以最終的結果應該是輸出 false。

下面再說一下為什麼說在 -128 和 127 以內的也不建議直接使用 == 來實現比較，很顯然就跟我們上面的genA() 方法一樣，很多時候不會一下子就知道一個方法值是怎麼得到，即使是快取範圍以內，別人也有可能是透過建構函式創建出來的，這樣我們在做比較的時候很有可能就會跟預期的不一樣，從而產生事故。

特別是如果透過 RPC 介面獲得返回結果，我們可能連別人的實現方式壓根就看不到，更沒辦法提前知道了。所以我們還是老老實實的按照阿里巴巴的 Java 規範來編寫程式碼，採用equals 方法來判斷，這樣肯定沒問題。

分類： 科技

時間： 2021-10-12