天天看點

為什麼阿裡巴巴Java開發手冊中強制要求整型包裝類對象值用 equals 方法比較?Integer 緩存問題分析源碼分析法反編譯法Long 的緩存問題分析反編譯總結

在閱讀《阿裡巴巴Java開發手冊》時,發現有一條關于整型包裝類對象之間值比較的規約,具體内容如下:

為什麼阿裡巴巴Java開發手冊中強制要求整型包裝類對象值用 equals 方法比較?Integer 緩存問題分析源碼分析法反編譯法Long 的緩存問題分析反編譯總結

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

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

1.如果不看《阿裡巴巴Java開發手冊》,如何知道 Integer var = ? 會緩存 -128 到 127 之間的指派?

2.為什麼會緩存這個範圍的指派?

3.如何學習和分析類似的問題?

先看下面的示例代碼,并思考該段代碼的輸出結果:

通過運作代碼可以得到答案,程式輸出的結果分别為:true , false。

那麼為什麼答案是這樣?

結合《阿裡巴巴Java開發手冊》的描述很多人可能會回答:因為緩存了 -128 到 127 之間的數值,就沒有然後了。

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

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

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

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

怎麼知道會調用 valueOf() 方法呢?

大家可以通過打斷點,運作程式後會調到這裡。

先看 java.lang.Integer#valueOf(int) 源碼:

通過源碼可以看出,如果用 Ineger.valueOf(int) 來建立整數對象,參數大于等于整數緩存的最小值( IntegerCache.low )并小于等于整數緩存的最大值( IntegerCache.high), 會直接從緩存數組 (java.lang.Integer.IntegerCache#cache) 中提取整數對象;否則會 new 一個整數對象。在 JDK9 直接把 new 的構造方法标記為 deprecated,推薦使用 valueOf(),合理利用緩存,提升程式性能。

那麼這裡的緩存最大和最小值分别是多少呢?

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

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

通過注釋我們可以得知:如果不要求必須建立一個整型對象,緩存最常用的值(提前構造緩存範圍内的整型對象),會更省空間,速度也更快。

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

如果想減少記憶體占用,提高程式運作的效率,可以将常用的對象提前緩存起來,需要時直接從緩存中提取。

那麼我們再思考下一個問題:Integer 緩存的區間可以修改嗎?

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

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

是以可以通過修改這兩個參數其中之一,讓緩存的最大值大于等于 666。

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

學到這裡是不是發現,對此問題的了解和最初的想法有些不同呢?

這段注釋也解答了為什麼要緩存這個範圍的資料:

是為了自動裝箱時可以複用這些對象 ,這也是 JLS2 的要求。

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

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

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

如果遇到其它類似的問題,沒人告訴我底層調用了哪個方法,該怎麼辦?

這類問題,可以通過對編譯後的 class 檔案進行反編譯來檢視。

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

然後需要對代碼進行反編譯,執行:javap -c IntegerTest

如果想了解 javap 的用法,直接輸入 javap -help 檢視用法提示(很多指令行工具都支援 -help 或 --help 給出用法提示)。

為什麼阿裡巴巴Java開發手冊中強制要求整型包裝類對象值用 equals 方法比較?Integer 緩存問題分析源碼分析法反編譯法Long 的緩存問題分析反編譯總結

反編譯後,我們得到以下代碼:

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

接下來對編譯後的代碼進行詳細分析,如果看不懂可略過:

根據《Java Virtual Machine Specification : Java SE 8 Edition》3,後縮寫為 JVMS , 第 6 章 虛拟機指令集的相關描述以及《深入了解 Java 虛拟機》4 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 的指令為 ifacmpn,該指令為條件跳轉指令,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 虛拟機規範》這本書進行拓展學習。

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

源碼分析

類似的,接下來分析 java.lang.Long#valueOf(long) 的源碼:

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

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

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

但是通過注釋我們發現這麼一段提示:

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

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

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

那麼 Long 類型的緩存是如何構造的呢?

我們檢視緩存數組的構造:

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

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

編譯源代碼:javac LongTest.java

對編譯後的類檔案進行反編譯: javap -c LongTest

得到下面反編譯的代碼:

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

事實上,除 Float 和 Double 外,其他包裝資料類型都會緩存,6 個包裝類直接指派時,就是調用對應包裝類的靜态工廠方法 valueOf()。

各個包裝類的緩存區間如下:

•Boolean:使用靜态 final 變量定義,valueOf() 就是傳回這兩個靜态值

•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 加入參數 -XX:AutoBoxCacheMax=666,即可設定最大緩存值為 666

另外,在選擇使用包裝類還是基本資料類型時,推薦使用如下方式:

1.所有的 POJO 類屬性必須使用包裝資料類型

2.RPC 方法的傳回值和參數必須使用包裝資料類型

3.所有的局部變量推薦使用基本資料類型

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

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

還介紹了其他包裝類型的緩存範圍,以及包裝類和基本資料類型的推薦使用場景。

參考

《Java開發手冊》華山版

《碼出高效:Java開發手冊》

《深入了解Java虛拟機》

●Java 中的 final、finally、finalize 有什麼不同?

●深入了解 Java 中的 final 關鍵字

●如何定制 Spring Boot 的 Banner?

●Java 異常處理的 20 個最佳實踐,你知道幾個?

●Java中Set集合是如何實作添加元素保證不重複的?

●為什麼不建議使用Date,而是使用Java8新的時間和日期API?

●Spring Boot 定時任務 @Scheduled

●為什麼阿裡巴巴Java開發手冊中不建議在循環體中使用+進行字元串拼接?

●MySQL 日志系統之 redo log 和 binlog

●從單體應用走向服務化

●什麼是微服務?

●一條SQL查詢語句是如何執行的?

為什麼阿裡巴巴Java開發手冊中強制要求整型包裝類對象值用 equals 方法比較?Integer 緩存問題分析源碼分析法反編譯法Long 的緩存問題分析反編譯總結

武培軒

有幫助?在看,轉發走一波

鐘意作者