為什么阿里巴巴Java開發(fā)手冊中強制要求整型包裝類對象值用 equals 方法比較？

在閱讀《阿里巴巴Java開發(fā)手冊》時，發(fā)現(xiàn)有一條關(guān)于整型包裝類對象之間值比較的規(guī)約，具體內(nèi)容如下：



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

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

* 如果不看《阿里巴巴Java開發(fā)手冊》，如何知道 Integer var = ? 會緩存 -128 到 127 之間的賦值？
* 為什么會緩存這個范圍的賦值？
* 如何學(xué)習(xí)和分析類似的問題？
Integer 緩存問題分析

先看下面的示例代碼，并思考該段代碼的輸出結(jié)果：
public class IntegerTest { public static void main(String[] args) { Integer a
= 100, b = 100, c = 666, d = 666; System.out.println(a == b);
System.out.println(c == d); } }
通過運行代碼可以得到答案，程序輸出的結(jié)果分別為： true , false。

那么為什么答案是這樣？

結(jié)合《阿里巴巴Java開發(fā)手冊》的描述很多人可能會回答：因為緩存了 -128 到 127 之間的數(shù)值，就沒有然后了。

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

接下來，讓我們一起進行分析。

源碼分析法

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

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

怎么知道會調(diào)用 valueOf() 方法呢？

大家可以通過打斷點，運行程序后會調(diào)到這里。

先看 java.lang.Integer#valueOf(int) 源碼：
/** * 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) 來創(chuàng)建整數(shù)對象，參數(shù)大于等于整數(shù)緩存的最小值（ IntegerCache.low
）并小于等于整數(shù)緩存的最大值（ IntegerCache.high）, 會直接從緩存數(shù)組
(java.lang.Integer.IntegerCache#cache) 中提取整數(shù)對象；否則會 new 一個整數(shù)對象。在 JDK9 直接把 new
的構(gòu)造方法標記為 deprecated，推薦使用 valueOf()，合理利用緩存，提升程序性能。

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

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

那么為什么會緩存這一段區(qū)間的整數(shù)對象呢？

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

這給我們一個非常重要的啟發(fā)：

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

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

通過上述源碼和注釋我們還無法回答這個問題，接下來，我們繼續(xù)看 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， 最大值并不是固定值，緩存的最大值是可以通過虛擬機參數(shù)
-XX:AutoBoxCacheMax=} 或 -Djava.lang.Integer.IntegerCache.high= 來設(shè)置的，未指定則為 127。

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

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

學(xué)到這里是不是發(fā)現(xiàn)，對此問題的理解和最初的想法有些不同呢？

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

是為了自動裝箱時可以復(fù)用這些對象 ，這也是 JLS2 的要求。

我們可以參考 JLS 的 Boxing Conversion 部分的相關(guān)描述。
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 類型的數(shù)值 p， 自動包裝成 a 和 b 兩個對象時， 可以使用 a == b 判斷 a
和 b 的值是否相等。

反編譯法

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

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

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

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

然后需要對代碼進行反編譯，執(zhí)行：javap -c IntegerTest

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



反編譯后，我們得到以下代碼：
Compiled from "IntegerTest.java" public class com.wupx.demo.IntegerTest {
public com.wupx.demo.IntegerTest(); 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 666 15: invokestatic #2 // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer; 18: astore_3 19: sipush 666
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)
來構(gòu)造 Integer 對象的。

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

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

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

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

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

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

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

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

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

由于該指令有以下特性：

if_acmpeq 比較棧兩個引用類型數(shù)值，相等則跳轉(zhuǎn)
if_acmpne 比較棧兩個引用類型數(shù)值，不相等則跳轉(zhuǎn)
由于 Integer 的緩存問題，所以 a 和 b 引用指向同一個地址，因此此條件不成立（成立則跳轉(zhuǎn)到偏移為 39 的指令處），執(zhí)行偏移為 35 的指令。

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

然后執(zhí)行偏移為 36 的 goto 指令，跳轉(zhuǎn)到偏移為 40 的指令。

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

可知參數(shù)描述符為 Z ，返回值描述符為 V。

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

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

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

執(zhí)行偏移為 60 的指令，即 retrun ，程序結(jié)束。

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

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

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

如果想深入學(xué)習(xí) java 反編譯，強烈建議結(jié)合官方的 JVMS 或其中文版:《Java 虛擬機規(guī)范》這本書進行拓展學(xué)習(xí)。

Long 的緩存問題分析

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

源碼分析

類似的，接下來分析 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); }
發(fā)現(xiàn)該函數(shù)的寫法和 Ineger.valueOf(int) 非常相似。

我們同樣也看到， Long 也用到了緩存。 使用 Ineger.valueOf(int) 構(gòu)造 Long 對象時，值在 [-128, 127] 之間的
Long 對象直接從緩存對象數(shù)組中提取。

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

但是通過注釋我們發(fā)現(xiàn)這么一段提示：
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 的緩存的注釋）。

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

那么 Long 類型的緩存是如何構(gòu)造的呢？

我們查看緩存數(shù)組的構(gòu)造：
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); } }
可以看到，它是在靜態(tài)代碼塊中填充緩存數(shù)組的。

反編譯

同樣地我們也編寫一個示例片段：
public class LongTest { public static void main(String[] args) { Long a =
-128L, b = -128L, c = 666L, d = 666L; System.out.println(a == b);
System.out.println(c == d); } }
編譯源代碼： javac LongTest.java

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

得到下面反編譯的代碼：
Compiled from "LongTest.java" public class com.wupx.demo.LongTest { public
com.wupx.demo.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
666l 17: invokestatic #4 // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;
20: astore_3 21: ldc2_w #5 // long 666l 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 }
從上述代碼中發(fā)現(xiàn) Long var = ? 的確是通過 java.lang.Long#valueOf(long) 來構(gòu)造對象的。

事實上，除 Float 和 Double 外，其他包裝數(shù)據(jù)類型都會緩存，6 個包裝類直接賦值時，就是調(diào)用對應(yīng)包裝類的靜態(tài)工廠方法 valueOf()。

各個包裝類的緩存區(qū)間如下：

* Boolean：使用靜態(tài) final 變量定義，valueOf() 就是返回這兩個靜態(tài)值
* Byte：表示范圍是 -128 ~ 127，全部緩存
* Short：表示范圍是 - 32768 ~ 32767，緩存范圍是 -128~127
* Character：表示范圍是 0 ~ 65535，緩存范圍是 0~127
* Long：表示范圍是 [-2^63 ~ 2^63-1]，緩存范圍是 -128~127
* Integer：表示范圍是 [-2^31 ~ 2^31-1]，緩存范圍是 -128~127，但它是唯一可以修改緩存范圍的包裝類，在 VM
options 加入?yún)?shù) -XX:AutoBoxCacheMax=6666，即可設(shè)置最大緩存值為 6666
另外，在選擇使用包裝類還是基本數(shù)據(jù)類型時，推薦使用如下方式：

* 所有的 POJO 類屬性必須使用包裝數(shù)據(jù)類型
* RPC 方法的返回值和參數(shù)必須使用包裝數(shù)據(jù)類型
* 所有的局部變量推薦使用基本數(shù)據(jù)類型
總結(jié)

本文首先對阿里巴巴Java開發(fā)手冊中強制要求整型包裝類對象值用 equals 方法比較作了簡單介紹，并通過源碼分析法、閱讀 JLS 和
JVMS、使用反編譯法，對 Integer 和 Long 緩存的目的和實現(xiàn)方式問題進行了深入分析。

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

還介紹了其他包裝類型的緩存范圍，以及包裝類和基本數(shù)據(jù)類型的推薦使用場景。

參考

《Java開發(fā)手冊》華山版

《碼出高效：Java開發(fā)手冊》

《深入理解Java虛擬機》

• ? 上一篇： 面試必問的4種單點登錄的實現(xiàn)方式，你知道幾個？
• ? 下一篇： OPPO數(shù)據(jù)中臺之基石：基于Flink SQL構(gòu)建實數(shù)據(jù)倉庫