慕課專欄

解鎖大廠思維：剖析《阿里巴巴 Java 開發手冊》/02 Integer緩存問題分析

索引目錄

解鎖大廠思維：剖析《阿里巴巴 Java 開發手冊》

原價￥ 68.00

立即訂閱

02 Integer緩存問題分析

更新時間：2019-11-26 09:43:03

我要扼住命運的咽喉，它妄想使我屈服，這絕對辦不到。生活是這樣美好，活他一千輩子吧！——貝多芬

1. 前言

《手冊》第 7 頁有一段關于包裝對象之間值的比較問題的規約 ¹：

【強制】所有整型包裝類對象之間值的比較，全部使用 equals 方法比較。
說明：對于 Integer var = ? 在 - 128 至 127 范圍內的賦值，Integer 對象是在 IntegerCache.cache 產生，會復用已有對象，這個區間內的 Integer 值可以直接使用 == 進行判斷，但是這個區間之外的所有數據，都會在堆上產生，并不會復用已有對象，這是一個大坑，推薦使用 equals 方法進行判斷。

這條建議非常值得大家關注，而且該問題在 Java 面試中十分常見。

我們還需要思考以下幾個問題：

如果不看《手冊》，我們如何知道 Integer var = ? 會緩存 -128 到 127 之間的賦值？
為什么會緩存這個范圍的賦值？
我們如何學習和分析類似的問題？

2.Integer 緩存問題分析

我們先看下面的示例代碼，并思考該段代碼的輸出結果：

public class IntTest {
	public static void main(String[] args) {
	    Integer a = 100, b = 100, c = 150, d = 150;
	    System.out.println(a == b);
	    System.out.println(c == d);
	}
}

通過運行代碼可以得到答案，程序輸出的結果分別為： true , false。

那么為什么答案是這樣？

結合《手冊》的描述很多人可能會頗有自信地回答：因為緩存了 -128 到 127 之間的數值，就沒有然后了。

那么為什么會緩存這一段區間的數值？緩存的區間可以修改嗎？其它的包裝類型有沒有類似緩存？

what? 咋還有這么多問題？這誰知道啊！

莫急，且看下面的分析。

2.1 源碼分析法

首先我們可以通過源碼對該問題進行分析。

我們知道，Integer var = ? 形式聲明變量，會通過 java.lang.Integer#valueOf(int) 來構造 Integer 對象。

很多人可能會說：“你咋能知道這個呢”？

如果不信大家可以打斷點，運行程序后會調到這里，總該信了吧？（后面還會再作解釋）。

我們先看該函數源碼：

/**
 * Returns an {@code Integer} instance representing the specified
 * {@code int} value.  If a new {@code Integer} instance is not
 * required, this method should generally be used in preference to
 * the constructor {@link #Integer(int)}, as this method is likely
 * to yield significantly better space and time performance by
 * caching frequently requested values.
 *
 * This method will always cache values in the range -128 to 127,
 * inclusive, and may cache other values outside of this range.
 *
 * @param  i an {@code int} value.
 * @return an {@code Integer} instance representing {@code i}.
 * @since  1.5
 */
public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

通過源碼可以看出，如果用 Ineger.valueOf(int) 來創建整數對象，參數大于等于整數緩存的最小值（ IntegerCache.low ）并小于等于整數緩存的最大值（ IntegerCache.high）, 會直接從緩存數組 (java.lang.Integer.IntegerCache#cache) 中提取整數對象；否則會 new 一個整數對象。

那么這里的緩存最大和最小值分別是多少呢？

從上述注釋中我們可以看出，最小值是 -128, 最大值是 127。

那么為什么會緩存這一段區間的整數對象呢？

通過注釋我們可以得知：如果不要求必須新建一個整型對象，緩存最常用的值（提前構造緩存范圍內的整型對象），會更省空間，速度也更快。

這給我們一個非常重要的啟發：

如果想減少內存占用，提高程序運行的效率，可以將常用的對象提前緩存起來，需要時直接從緩存中提取。

那么我們再思考下一個問題： Integer 緩存的區間可以修改嗎？

通過上述源碼和注釋我們還無法回答這個問題，接下來，我們繼續看 java.lang.Integer.IntegerCache 的源碼：

/**
 * Cache to support the object identity semantics of autoboxing for values between
 * -128 and 127 (inclusive) as required by JLS.
 *
 * The cache is initialized on first usage.  The size of the cache
 * may be controlled by the {@code -XX:AutoBoxCacheMax=<size>} option.
 * During VM initialization, java.lang.Integer.IntegerCache.high property
 * may be set and saved in the private system properties in the
 * sun.misc.VM class.
 */

private static class IntegerCache {
    static final int low = -128;
    static final int high;
    static final Integer cache[];
    static {
            // high value may be configured by property
            int h = 127;
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
           // 省略其它代碼
    }
      // 省略其它代碼
}

通過 IntegerCache 代碼和注釋我們可以看到，最小值是固定值 -128，最大值并不是固定值，緩存的最大值是可以通過虛擬機參數 -XX:AutoBoxCacheMax=<size>} 或 -Djava.lang.Integer.IntegerCache.high=<value> 來設置的，未指定則為 127。

因此可以通過修改這兩個參數其中之一，讓緩存的最大值大于等于 150。

如果作出這種修改，示例的輸出結果便會是： true,true。

學到這里是不是發現，對此問題的理解和最初的想法有些不同呢？

這段注釋也解答了為什么要緩存這個范圍的數據：

是為了自動裝箱時可以復用這些對象 ，這也是 JLS² 的要求。

我們可以參考 JLS 的 Boxing Conversion 部分的相關描述。

If the valuepbeing boxed is an integer literal of type intbetween -128and 127inclusive (§3.10.1), or the boolean literal trueorfalse(§3.10.3), or a character literal between '\u0000'and '\u007f'inclusive (§3.10.4), then let aand bbe the results of any two boxing conversions of p. It is always the case that a==b.

在 -128 到 127 （含）之間的 int 類型的值，或者 boolean 類型的 true 或 false，以及范圍在’\u0000’和’\u007f’ （含）之間的 char 類型的數值 p，自動包裝成 a 和 b 兩個對象時，可以使用 a == b 判斷 a 和 b 的值是否相等。

2.2 反匯編法

那么究竟 Integer var = ? 形式聲明變量，是不是通過 java.lang.Integer#valueOf(int) 來構造 Integer 對象呢？總不能都是猜測 N 個可能的函數，然后斷點調試吧？

如果遇到其它類似的問題，沒人告訴我底層調用了哪個方法，該怎么辦？ 囧…

這類問題有個殺手锏，可以通過對編譯后的 class 文件進行反匯編來查看。

首先編譯源代碼：javac IntTest.java

然后需要對代碼進行反匯編，執行：javap -c IntTest

如果想了解 javap 的用法，直接輸入 javap -help 查看用法提示（很多命令行工具都支持 -help 或 --help 給出用法提示）。

反編譯后，我們得到以下代碼：

Compiled from "IntTest.java"
public class com.chujianyun.common.int_test.IntTest {
  public com.chujianyun.common.int_test.IntTest();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: bipush        100
       2: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
       5: astore_1
       6: bipush        100
       8: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      11: astore_2
      12: sipush        150
      15: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      18: astore_3
      19: sipush        150
      22: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      25: astore        4
      27: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
      30: aload_1
      31: aload_2
      32: if_acmpne     39
      35: iconst_1
      36: goto          40
      39: iconst_0
      40: invokevirtual #4                  // Method java/io/PrintStream.println:(Z)V
      43: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
      46: aload_3
      47: aload         4
      49: if_acmpne     56
      52: iconst_1
      53: goto          57
      56: iconst_0
      57: invokevirtual #4                  // Method java/io/PrintStream.println:(Z)V
      60: return
}

可以明確得 "看到" 這四個 ``Integer var = ? 形式聲明的變量的確是通過 java.lang.Integer#valueOf(int) 來構造 Integer` 對象的。

接下來對匯編后的代碼進行詳細分析，如果看不懂可略過：

根據《Java Virtual Machine Specification : Java SE 8 Edition》³，后縮寫為 JVMS , 第 6 章虛擬機指令集的相關描述以及《深入理解 Java 虛擬機》⁴ 414-149 頁的附錄 B “虛擬機字節碼指令表”。我們對上述指令進行解讀：

偏移為 0 的指令為：bipush 100 ，其含義是將單字節整型常量 100 推入操作數棧的棧頂；

偏移為 2 的指令為：invokestatic #2 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer; 表示調用一個 static 函數，即 java.lang.Integer#valueOf(int)；

偏移為 5 的指令為：astore_1 ，其含義是從操作數棧中彈出對象引用，然后將其存到第 1 個局部變量 Slot 中；

偏移 6 到 25 的指令和上面類似；

偏移為 30 的指令為 aload_1 ，其含義是從第 1 個局部變量 Slot 取出對象引用（即 a），并將其壓入棧；

偏移為 31 的指令為 aload_2 ，其含義是從第 2 個局部變量 Slot 取出對象引用（即 b），并將其壓入棧；

偏移為 32 的指令為 if_acmpn，該指令為條件跳轉指令，if_ 后以 a 開頭表示對象的引用比較。

由于該指令有以下特性：

if_acmpeq 比較棧兩個引用類型數值，相等則跳轉

if_acmpne 比較棧兩個引用類型數值，不相等則跳轉

由于 Integer 的緩存問題，所以 a 和 b 引用指向同一個地址，因此此條件不成立（成立則跳轉到偏移為 39 的指令處），執行偏移為 35 的指令。

偏移為 35 的指令: iconst_1，其含義為將常量 1 壓棧（ Java 虛擬機中 boolean 類型的運算類型為 int ，其中 true 用 1 表示，詳見 2.11.1 數據類型和 Java 虛擬機。

然后執行偏移為 36 的 goto 指令，跳轉到偏移為 40 的指令。

偏移為 40 的指令：invokevirtual #4 // Method java/io/PrintStream.println:(Z)V。

可知參數描述符為 Z ，返回值描述符為 V。

根據 4.3.2 字段描述符，可知 FieldType 的字符為 Z 表示 boolean 類型，值為 true 或 false。
根據 4.3.3 字段描述符，可知返回值為 void。

因此可以知，最終調用了 java.io.PrintStream#println(boolean) 函數打印棧頂常量即 true。

然后比較執行偏移 43 到 57 之間的指令，比較 c 和 d，打印 false 。

執行偏移為 60 的指令，即 retrun ，程序結束。

可能有些朋友會對反匯編的代碼有些抵觸和恐懼，這都是非常正常的現象。

我們分析和研究問題的時候，看懂核心邏輯即可，不要糾結于細節，而失去了重點。

一回生兩回熟，隨著遇到的例子越來越多，遇到類似的問題時，會喜歡上 javap 來分析和解決問題。

如果想深入學習 java 反匯編，強烈建議結合官方的 JVMS 或其中文版:《Java 虛擬機規范》這本書進行拓展學習。

如果大家不喜歡命令行的方式進行 Java 的反匯編，這里推薦一個簡單易用的可視化工具：classpy ，大家可以自行了解學習。

3.Long 的緩存問題分析

我們學習的目的之一就是要學會舉一反三。因此我們對 Long 也進行類似的研究，探究兩者之間有何異同。

3.1 源碼分析

類似的，我們接下來分析 java.lang.Long#valueOf(long) 的源碼：

/**
 * Returns a {@code Long} instance representing the specified
 * {@code long} value.
 * If a new {@code Long} instance is not required, this method
 * should generally be used in preference to the constructor
 * {@link #Long(long)}, as this method is likely to yield
 * significantly better space and time performance by caching
 * frequently requested values.
 *
 * Note that unlike the {@linkplain Integer#valueOf(int)
 * corresponding method} in the {@code Integer} class, this method
 * is <em>not</em> required to cache values within a particular
 * range.
 *
 * @param  l a long value.
 * @return a {@code Long} instance representing {@code l}.
 * @since  1.5
 */
public static Long valueOf(long l) {
    final int offset = 128;
    if (l >= -128 && l <= 127) { // will cache
        return LongCache.cache[(int)l + offset];
    }
    return new Long(l);
}

發現該函數的寫法和 Ineger.valueOf(int) 非常相似。

我們同樣也看到， Long 也用到了緩存。使用 java.lang.Long#valueOf(long) 構造 Long 對象時，值在 [-128, 127] 之間的 Long 對象直接從緩存對象數組中提取。

而且注釋同樣也提到了：緩存的目的是為了提高性能。

但是通過注釋我們發現這么一段提示：

Note that unlike the {@linkplain Integer#valueOf(int) corresponding method} in the {@code Integer} class, this method is not required to cache values within a particular range.

注意：和 Ineger.valueOf(int) 不同的是，此方法并沒有被要求緩存特定范圍的值。

這也正是上面源碼中緩存范圍判斷的注釋為何用 // will cache 的原因（可以對比一下上面 Integer 的緩存的注釋）。

因此我們可知，雖然此處采用了緩存，但應該不是 JLS 的要求。

那么 Long 類型的緩存是如何構造的呢？

我們查看緩存數組的構造：

private static class LongCache {
    private LongCache(){}

    static final Long cache[] = new Long[-(-128) + 127 + 1];

    static {
        for(int i = 0; i < cache.length; i++)
            cache[i] = new Long(i - 128);
    }
}

可以看到，它是在靜態代碼塊中填充緩存數組的。

3.2 反編譯

同樣地我們也編寫一個示例片段：

public class LongTest {

    public static void main(String[] args) {
        Long a = -128L, b = -128L, c = 150L, d = 150L;
        System.out.println(a == b);
        System.out.println(c == d);
    }
}

編譯源代碼： javac LongTest.java

對編譯后的類文件進行反匯編: javap -c LongTest

得到下面反編譯的代碼：

public class com.imooc.basic.learn_int.LongTest {
  public com.imooc.basic.learn_int.LongTest();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: ldc2_w        #2                  // long -128l
       3: invokestatic  #4                  // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
       6: astore_1
       7: ldc2_w        #2                  // long -128l
      10: invokestatic  #4                  // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
      13: astore_2
      14: ldc2_w        #5                  // long 150l
      17: invokestatic  #4                  // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
      20: astore_3
      21: ldc2_w        #5                  // long 150l
      24: invokestatic  #4                  // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
      27: astore        4
      29: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
      32: aload_1
      33: aload_2
      34: if_acmpne     41
      37: iconst_1
      38: goto          42
      41: iconst_0
      42: invokevirtual #8                  // Method java/io/PrintStream.println:(Z)V
      45: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
      48: aload_3
      49: aload         4
      51: if_acmpne     58
      54: iconst_1
      55: goto          59
      58: iconst_0
      59: invokevirtual #8                  // Method java/io/PrintStream.println:(Z)V
      62: return
}

我們從上述代碼中發現 Long var = ? 的確是通過 java.lang.Long#valueOf(long) 來構造對象的。

3. 總結

本小節通過源碼分析法、閱讀 JLS 和 JVMS、使用反匯編法，對 Integer 和 Long 緩存的目的和實現方式問題進行了深入分析。

讓大家能夠通過更豐富的手段來學習知識和分析問題，通過對緩存目的的思考來學到更通用和本質的東西。

本節使用的幾種手段將是我們未來常用的方法，也是工作進階的必備技能和一個程序員專業程度的體現，希望大家未來能夠多動手實踐。

下一節我們將介紹 Java 序列化相關問題，包括序列化的定義，序列化常見的方案，序列化的坑點等。

4. 課后題

第 1 題：請大家根據今天的研究分析過程，對下面的一個示例代碼進行分析。

public class CharacterTest {
    public static void main(String[] args) {
        Character a = 126, b = 126, c = 128, d = 128;
        System.out.println(a == b);
        System.out.println(c == d);
    }
}

第 2 題：結合今天的講解，請自行對 Character、 Short 、Boolean 的緩存問題進行分析，并比較它們的異同。

參考資料

阿里巴巴與 Java 社區開發者.《 Java 開發手冊 1.5.0》華山版. 2019. 7 ??
James Gosling, Bill Joy, Guy Steele, Gilad Bracha, Alex Buckley.《Java Language Specification: Java SE 8 Edition》. 2015 ??
Tim Lindholm, Frank Yellin, Gilad Bracha, Alex Buckley. 《Java Virtual Machine Specification : Java SE 8 Edition》. 2015 ??
周志明.《深入理解 Java 虛擬機》. 機械工業出版社. 2018 ??

}

立即訂閱￥ 68.00

你正在閱讀課程試讀內容，訂閱后解鎖課程全部內容

千學不如一看，千看不如一練

留言

手機
閱讀

掃一掃手機閱讀

回頂部