干了這么多年Java被問得最多的幾個(gè)基礎(chǔ)問題里包裝類和泛型一定排得上前三。尤其是面試的時(shí)候十個(gè)里面有八個(gè)會問Integer緩存和ListString能不能轉(zhuǎn)成ListObject這種題。但說實(shí)話很多人是背了答案真正遇到線上問題的時(shí)候還是一臉懵——我就親眼見過同事因?yàn)槟帽容^兩個(gè)Integer而查了一下午bug最后發(fā)現(xiàn)是緩存機(jī)制在搗鬼。今天這篇不打算按教科書的路子講我從實(shí)際使用和踩坑的角度把Java-9 包裝類和泛型這塊徹底捋一遍。重點(diǎn)講清楚三件事包裝類為什么必須存在、它的緩存和判等機(jī)制到底怎么回事、以及泛型在JVM里是怎么騙過編譯器的。不管你是在準(zhǔn)備Java面試、剛?cè)腴T想夯實(shí)基礎(chǔ)還是寫了幾年代碼但一直沒搞透這些底層機(jī)制這篇都能給你一些實(shí)操層面的啟發(fā)。1. 從字節(jié)碼到緩存池包裝類為什么必須存在1.1 一個(gè)讓int變成對象的設(shè)計(jì)動機(jī)先從一個(gè)最樸素的問題開始Java里明明已經(jīng)有int、double、boolean這些基本類型為什么要搞出Integer、Double、Boolean這一堆包裝類答案其實(shí)藏在Java的萬物皆對象口號里。Java號稱面向?qū)ο蟮绢愋推皇菍ο蟆悴荒苷{(diào)用int的方法不能把它直接扔進(jìn)Object類型的變量里更不能塞進(jìn)集合框架。不信你試試Listint list new ArrayList(); // 編譯直接報(bào)錯(cuò)集合框架清一色只接受對象int這種基本類型根本不讓你進(jìn)。而包裝類就是給基本類型穿的一件對象外衣int變成Integerchar變成Characterboolean變成Boolean。穿上這件外衣之后基本類型值才可以去任何對象該去的地方——放進(jìn)集合、作為泛型參數(shù)、賦給Object引用、甚至當(dāng)作null。這套設(shè)計(jì)還有一個(gè)實(shí)際意義基本類型沒有空值的概念。你聲明一個(gè)int它至少是0但數(shù)據(jù)庫里查出來一個(gè)字段沒有值你怎么用int表達(dá)只能靠Integer的null。所以做ORM映射、JSON序列化的時(shí)候Integer這種包裝類型幾乎是標(biāo)配。1.2 八個(gè)包裝類的繼承脈絡(luò)Java一共提供了八個(gè)包裝類對應(yīng)八種基本類型。我畫了個(gè)對照表方便你記基本類型包裝類父類可比較性booleanBooleanObject實(shí)現(xiàn)ComparableBooleanbyteByteNumber實(shí)現(xiàn)ComparableBytecharCharacterObject實(shí)現(xiàn)ComparableCharactershortShortNumber實(shí)現(xiàn)ComparableShortintIntegerNumber實(shí)現(xiàn)ComparableIntegerlongLongNumber實(shí)現(xiàn)ComparableLongfloatFloatNumber實(shí)現(xiàn)ComparableFloatdoubleDoubleNumber實(shí)現(xiàn)ComparableDouble其中六個(gè)數(shù)值型的包裝類都繼承自抽象類Number這也是為什么你可以用Integer d new Integer(10); double x d.doubleValue();這樣任意轉(zhuǎn)換數(shù)值類型。而Boolean和Character不走這條路因?yàn)樗鼈兒蛿?shù)值無關(guān)。還有一個(gè)隱藏細(xì)節(jié)值得注意所有包裝類都是final的不允許被繼承。這個(gè)設(shè)計(jì)不是拍腦袋定的——如果允許繼承Integer子類完全可以重寫equals或者h(yuǎn)ashCode那整個(gè)包裝類的一致性體系就崩了。JVM底層很多優(yōu)化都依賴包裝類是不可變的、值是安全的這一假設(shè)。1.3 包裝類在字節(jié)碼層面的真實(shí)面目很多人只知道自動裝箱/拆箱這個(gè)詞但不知道底層發(fā)生了什么。我反編譯過一段最簡單的代碼Integer a 100; // 裝箱 int b a; // 拆箱字節(jié)碼對應(yīng)的關(guān)鍵指令其實(shí)是這樣Integer a Integer.valueOf(100); // 裝箱調(diào)用valueOf int b a.intValue(); // 拆箱調(diào)用intValue所以自動只是語法糖底層是老老實(shí)實(shí)調(diào)方法。這里有個(gè)性能提示循環(huán)里頻繁裝箱拆箱會創(chuàng)建大量臨時(shí)對象對性能敏感的場景建議直接用基本類型計(jì)算別讓編譯器給你幫忙。2. 自動裝箱與緩存機(jī)制127和128之間差了一個(gè)Bug2.1 為什么Integer a 127和a b時(shí)而相等時(shí)而不等下面這幾行代碼幾乎是Java面試的必考送分題Integer a 127; Integer b 127; System.out.println(a b); // 輸出true Integer c 128; Integer d 128; System.out.println(c d); // 輸出false第一次看到這個(gè)結(jié)果的讀者肯定會懵同樣是賦值怎么換個(gè)數(shù)字結(jié)果就變了原因出在上節(jié)提到的Integer.valueOf()方法內(nèi)部。這個(gè)方法不是每次都new Integer()而是先查緩存如果值在緩存范圍內(nèi)直接返回緩存中已存在的對象否則才新建對象。JDK里Integer默認(rèn)緩存了-128到127這個(gè)區(qū)間的對象所以在這個(gè)范圍內(nèi)a和b拿到的實(shí)際上是同一個(gè)對象比較引用自然相等。而超出范圍后c和d各自new了一個(gè)新對象引用不同就返回false了。2.2 緩存范圍的默認(rèn)值與JLS的硬性規(guī)定你可能要問為什么偏偏是-128到127這個(gè)區(qū)間不是隨便定的。JLSJava語言規(guī)范里明確要求裝箱時(shí)如果數(shù)值在-128到127之間必須緩存并復(fù)用對象。下界-128固定不變上界127則可以通過JVM參數(shù)-XX:AutoBoxCacheMaxsize調(diào)大但即使調(diào)大規(guī)范也只保證默認(rèn)區(qū)間內(nèi)的行為是一致的。其他包裝類也有自己的緩存范圍我整理了個(gè)表包裝類緩存范圍說明Integer-128 ~ 127上界可通過JVM參數(shù)調(diào)整Long-128 ~ 127固定不可調(diào)Short-128 ~ 127固定不可調(diào)Byte全部范圍-128 ~ 127本身就是這么點(diǎn)數(shù)Character0 ~ 127只緩存ASCII范圍內(nèi)Booleantrue / false只有兩個(gè)實(shí)例Float / Double無緩存每次都是新對象看到?jīng)]Float和Double根本沒有緩存——浮點(diǎn)數(shù)的取值空間太大緩存沒有意義所以哪怕1.0f這種看起來很小的數(shù)字用比較也永遠(yuǎn)不等。2.3 自動拆箱是雙刃劍包裝類參與運(yùn)算的隱患自動拆箱還有一個(gè)特別容易踩的坑包裝類型做算術(shù)運(yùn)算時(shí)會先自動拆成基本類型再計(jì)算。Integer x 1000; Integer y 1000; Integer z x y;x y的時(shí)候編譯器先調(diào)用x.intValue()和y.intValue()得到兩個(gè)int相加結(jié)果再裝箱成Integer。這個(gè)過程本身沒錯(cuò)問題是如果x或者y是null呢Integer x null; int y x 1; // 空指針異常x 1會嘗試對null調(diào)用intValue()直接拋NullPointerException。這就是為什么在寫業(yè)務(wù)代碼時(shí)從數(shù)據(jù)庫或接口里拿到的包裝類型做任何運(yùn)算前都建議先判空。3. 包裝類判等中的經(jīng)典翻車現(xiàn)場與equals的分界線3.1 三個(gè)案例搞懂引用比較與值比較很多剛?cè)胄械拈_發(fā)都是從比較對象引用equals比較對象內(nèi)容這句話開始的。但這句話放在包裝類場景下還遠(yuǎn)遠(yuǎn)不夠。我直接用三個(gè)案例說明// 案例一緩存范圍內(nèi) Integer a 127; Integer b 127; System.out.println(a b); // true System.out.println(a.equals(b)); // true // 案例二超出緩存范圍 Integer a 128; Integer b 128; System.out.println(a b); // false System.out.println(a.equals(b)); // true // 案例三一邊是int一邊是Integer Integer a new Integer(100); int b 100; System.out.println(a b); // true案例三很多人想不明白前面不是剛說比較引用嗎為什么Integer和int比較返回true關(guān)鍵在于只要兩邊有一個(gè)是基本類型編譯器就會把另一個(gè)自動拆箱拆完之后兩個(gè)int用比數(shù)值自然相等。這種不對稱的行為最容易造成迷惑——你以為自己在比引用其實(shí)編譯器已經(jīng)偷偷幫你拆了箱。3.2 一個(gè)商品價(jià)格比較引發(fā)的線上問題說個(gè)我真實(shí)經(jīng)歷過的案例。有個(gè)同事寫訂單金額比較的邏輯代碼大概是這樣的public boolean samePrice(Integer price1, Integer price2) { return price1 price2; }測試的時(shí)候他拿100和100傳進(jìn)去跑得歡歡喜喜結(jié)果上了生產(chǎn)用戶反饋訂單金額明明一樣卻提示不一致定位半天發(fā)現(xiàn)線上金額超過127之后這個(gè)就失靈了。原因你肯定已經(jīng)明白了金額超過緩存范圍兩個(gè)Integer對象引用不相等。這個(gè)案例的教訓(xùn)很直接包裝類之間做值比較一律用equals()或者更穩(wěn)妥一點(diǎn)用Objects.equals()判空又判值。public boolean samePrice(Integer price1, Integer price2) { return Objects.equals(price1, price2); }Objects.equals內(nèi)部會先判null再調(diào)equals能避免你手寫判空邏輯時(shí)漏掉的情況。順帶提一句如果要比較的是多個(gè)值比如金額加數(shù)量可以封裝成一個(gè)小對象再重寫equals和hashCode別在業(yè)務(wù)代碼里連寫一大串。3.3equals方法的重寫邏輯所有包裝類都遵循同一套規(guī)則包裝類的equals實(shí)現(xiàn)邏輯很統(tǒng)一先判斷對方是不是同類是就比較內(nèi)部的值不是就直接返回false。以Integer為例偽代碼就是public boolean equals(Object obj) { if (obj instanceof Integer) { return value ((Integer) obj).intValue(); } return false; }注意一個(gè)細(xì)節(jié)Integer(100).equals(Long(100L))返回的是false因?yàn)轭愋投疾灰粯?。所以你在寫比較邏輯的時(shí)候不要指望跨類型的包裝類能曲線相等。另外正因?yàn)槊總€(gè)包裝類都重寫了equals和hashCode它們才能作為HashMap的鍵安全使用——這點(diǎn)和后面要講的泛型結(jié)合得非常緊密。4. 泛型的本質(zhì)是編譯期把戲類型擦除到底擦掉了什么4.1 泛型信息在運(yùn)行時(shí)是不存在的聊完包裝類接著聊泛型。泛型最反直覺的一點(diǎn)就是你在代碼里寫的ListString、ListInteger編譯之后根本不留痕跡。先看這個(gè)經(jīng)典例子ListString stringList new ArrayList(); ListInteger integerList new ArrayList(); System.out.println(stringList.getClass() integerList.getClass()); // true兩個(gè)不同類型的集合運(yùn)行時(shí)getClass()返回的都是ArrayList.class。這說明什么說明String和Integer這些類型參數(shù)在字節(jié)碼里根本沒有被保留下來泛型信息對 JVM 來說是不存在的。這就是所謂的類型擦除Type Erasure。編譯器拿到泛型之后做兩件事第一在編譯期做嚴(yán)格的類型檢查防止你把String塞進(jìn)ListInteger第二把類型參數(shù)替換成它的上界如果沒有指定上界就替換成Object并自動插入必要的強(qiáng)轉(zhuǎn)。ListString list new ArrayList(); list.add(hello); String s list.get(0);上面這段代碼編譯后的邏輯等價(jià)于List list new ArrayList(); list.add(hello); // 檢查通過直接add Object String s (String) list.get(0); // 自動插入強(qiáng)轉(zhuǎn)所以泛型對你來說是類型安全的盔甲對JVM來說只是編譯期的規(guī)范。4.2 擦除帶來的三條鐵律new T、instanceof、泛型數(shù)組理解了擦除很多泛型里的奇怪限制就順理成章了。鐵律一不能new T()。public T T create() { return new T(); // 編譯錯(cuò)誤Type parameter T cannot be instantiated directly }因?yàn)門在運(yùn)行時(shí)不復(fù)存在JVM 根本不知道要new什么類。你不是不想寫而是沒法寫。鐵律二不能instanceof T。同理運(yùn)行期的類型信息已經(jīng)擦除T只是個(gè)占位符instanceof判斷無從談起。鐵律三不能創(chuàng)建泛型數(shù)組。T[] array new T[10]; // 編譯錯(cuò)誤數(shù)組是協(xié)變的運(yùn)行時(shí)必須知道確切類型而泛型擦除后數(shù)組無法驗(yàn)證元素類型。實(shí)際開發(fā)中要表達(dá)泛型數(shù)組的需求通常用ListT替代或者用(T[]) new Object[10]加點(diǎn)SuppressWarnings(unchecked)但這兩者都不是首選。4.3 橋方法泛型擦除后的補(bǔ)丁術(shù)還有一個(gè)容易被忽略但面試偶爾會問的細(xì)節(jié)——橋方法bridge method。當(dāng)一個(gè)類實(shí)現(xiàn)了一個(gè)泛型接口時(shí)編譯器可能悄悄生成一個(gè)橋接方法保證多態(tài)行為在擦除后依然正確。interface ComparableT { int compareTo(T o); } class String implements ComparableString { public int compareTo(String o) { /* ... */ } }擦除后Comparable接口里的compareTo參數(shù)變成了Object但String類里只寫了compareTo(String)這個(gè)方法的參數(shù)類型對不上。編譯器于是自動補(bǔ)一個(gè)橋方法public int compareTo(Object o) { return compareTo((String) o); }橋方法本身是個(gè)膠水讓舊代碼以O(shè)bject調(diào)用的代碼能正確轉(zhuǎn)發(fā)到新的泛型方法上。這也是為什么有時(shí)候你在反射里看到類的方法數(shù)量比自己寫的多——多出來的大概率就是橋方法。5. 泛型的邊界藝術(shù)通配符、上下界限定與PECS原則5.1? extends T和? super T到底在限制什么剛才講了泛型火的本質(zhì)現(xiàn)在聊聊泛型邊界——這幾乎是面試的進(jìn)階題也是很多人在代碼里看到? extends和? super就頭大的地方。我先用一句話概括extends限制了讀出來的類型底線super限制了能寫進(jìn)去的類型上線但這句還是太抽象直接用代碼說話。List? extends Number numbers new ArrayListInteger(); Number n numbers.get(0); // 可以讀讀出來肯定是Number的子類 numbers.add(new Integer(1)); // 編譯錯(cuò)誤不能寫為什么不能寫因?yàn)閚umbers引用的實(shí)際類型可能是ListInteger、ListDouble、ListBigDecimal編譯器不確定你add進(jìn)去的元素能不能被這個(gè)未知的具體列表接受。為了防止運(yùn)行時(shí)類型混亂編譯器干脆禁止除了null以外的所有寫入。反過來看superList? super Integer list new ArrayListNumber(); list.add(123); // 可以寫因?yàn)镮nteger一定是Number的子類 Object obj list.get(0); // 讀出來只能是Object因?yàn)槟悴恢朗荖umber還是Integer還是Object這時(shí)候讀就受限了因?yàn)閷?shí)際列表可能是ListNumber也可能是ListObject取出來的元素沒法確定具體類型只有Object是安全的。5.2 PECSProducer Extends, Consumer Super編程里有個(gè)經(jīng)典口訣叫PECSProducer Extends, Consumer Super意思是如果你要從集合里讀取元素生產(chǎn)者用extends如果你要把元素寫入集合消費(fèi)者用super。這在寫Java工具類時(shí)非常常用。舉個(gè)實(shí)際例子一個(gè)從集合里提取最大值的通用方法public static T extends Comparable? super T T max(List? extends T list) { T max list.get(0); for (T item : list) { if (item.compareTo(max) 0) { max item; } } return max; }這段簽名里出現(xiàn)了兩個(gè)邊界T extends Comparable? super T要求T必須是可比較的而且T的父類也能比較它自己這是Collections.max的經(jīng)典簽名List? extends T傳入的列表元素類型必須是T的子類型。這個(gè)簽名不是炫技它解決了父子類集合不能互相賦值的痛點(diǎn)。比如你有一個(gè)ListInteger想調(diào)用一個(gè)接收ListNumber的方法直接傳是編譯不過的。這是因?yàn)榉盒筒粎f(xié)變ListInteger不是ListNumber的子類型。用List? extends Number就繞開了這個(gè)限制允許傳入任何Number子類的集合。5.3 泛型方法靜態(tài)上下文里的隱形尾巴泛型方法也是容易寫錯(cuò)的地方。最常見的一個(gè)坑是靜態(tài)方法里不能直接用類的泛型參數(shù)。public class UtilT { public static T getValue() { // 編譯錯(cuò)誤 return null; } }靜態(tài)方法和類無關(guān)T在靜態(tài)上下文里沒有綁定實(shí)例所以根本不知道T是什么。正確的做法是把泛型聲明挪到方法上public class Util { public static T T getValue(MapString, T map, String key) { return map.get(key); } }這里T放在返回值前面意思是這個(gè)方法是泛型方法T由調(diào)用時(shí)的參數(shù)推斷。調(diào)用的時(shí)候也不用特意寫類型參數(shù)Java會通過方法參數(shù)自動推斷這和類泛型的使用體驗(yàn)完全不同。6. 泛型和包裝類在集合框架中的協(xié)作以及Java 9的點(diǎn)滴變化6.1 集合框架里的黃金搭檔泛型參數(shù)必須是對象把包裝類和泛型放到一起看它們其實(shí)是一對黃金搭檔。泛型參數(shù)要求是引用類型不能是基本類型所以當(dāng)你需要存儲數(shù)字列表的時(shí)候只能用Integer而不是intListInteger scores new ArrayList(); scores.add(95); // 自動裝箱 int s scores.get(0); // 自動拆箱這里又有自動裝箱拆箱的參與了。每次add都會把int裝成Integer對象每次讀取又會拆回int。如果這個(gè)集合經(jīng)常被遍歷裝箱拆箱產(chǎn)生的臨時(shí)對象會成為一個(gè)隱藏的性能損耗。優(yōu)化方案很直接大數(shù)據(jù)量、高頻讀寫的數(shù)值集合可以考慮用專門的原始類型集合庫比如fastutil或者Trove或者干脆用int[]數(shù)組別追求代碼寫法好看而犧牲性能。6.2 遇到null就炸的自動拆箱集合判空不能偷懶集合里的包裝類型還有一個(gè)特性剛才沒展開說拆箱遇到null就炸?？催@個(gè)業(yè)務(wù)場景MapString, Integer orderCount ...; int count orderCount.get(customer_001);如果map里沒有這個(gè)鍵get返回的是null賦給int時(shí)會自動拆箱直接空指針。這種問題在寫報(bào)表、做統(tǒng)計(jì)的時(shí)候特別容易發(fā)生——數(shù)據(jù)庫里某個(gè)字段本來就是空的你拿到的Integer是null一參與運(yùn)算就崩。我的習(xí)慣是所有從集合或Map里取出來的包裝類型要么先判null要么用map.getOrDefault(key, 0)兜底別迷信這個(gè)值一定存在。寫代碼的時(shí)候多寫一行判空線上就能少一次半夜被電話叫醒的體驗(yàn)。6.3 Java 9帶來的兩個(gè)實(shí)用變化不可變集合與匿名內(nèi)部類的鉆石操作符標(biāo)題里帶了Java-9那就專門說說Java 9在包裝類和泛型這個(gè)領(lǐng)域帶來的兩個(gè)實(shí)用變化。第一個(gè)變化List.of、Map.of工廠方法。Java 9之前創(chuàng)建一個(gè)不可變的、元素確定的集合要寫很多行ListInteger list new ArrayList(); list.add(1); list.add(2); list.add(3); list Collections.unmodifiableList(list);Java 9之后一行搞定ListInteger scores List.of(95, 88, 76); MapString, Long counts Map.of(orders, 100L, users, 50L);這里有個(gè)細(xì)節(jié)List.of接收的是Integer不是int同樣是自動裝箱幫了忙。另外List.of不允許包含null元素也不允許修改適合表達(dá)那些配置好了就不允許變的數(shù)據(jù)。第二個(gè)變化匿名內(nèi)部類可以使用鉆石操作符。在Java 8及之前匿名內(nèi)部類里寫泛型必須帶上具體類型ComparatorString comparator new ComparatorString() { Override public int compare(String s1, String s2) { return s1.compareTo(s2); } };Java 9允許你簡化ComparatorString comparator new Comparator() { Override public int compare(String s1, String s2) { return s1.compareTo(s2); } };別小看這個(gè)變化在寫測試代碼或者臨時(shí)的策略類時(shí)少敲幾個(gè)字符事小代碼整潔度提升是實(shí)打?qū)嵉摹?. 一份避坑清單包裝類與泛型混用的實(shí)戰(zhàn)經(jīng)驗(yàn)寫到這里把我在實(shí)際開發(fā)和代碼審查里見過的高頻問題整理成一份避坑清單都是真實(shí)踩過的或者幫別人擦過屁股的第一能用int別用Integer的場合絕對不猶豫。局部變量計(jì)算、循環(huán)索引、金額運(yùn)算的中間結(jié)果這些場景基本類型沒有null的概念也不會有拆箱空指針的坑性能還更好。只有在需要可空語義或者必須放進(jìn)集合/泛型時(shí)才用包裝類。第二極少數(shù)場景別碰new Integer()。從Java 9開始new Integer()這個(gè)構(gòu)造器就被標(biāo)記為過時(shí)了。以前有人習(xí)慣用new Integer(100)來確保新建對象以繞過緩存問題這種做法現(xiàn)在已經(jīng)不推薦。要用包裝類就直接賦值讓valueOf去決定走緩存還是新建。第三switch對包裝類型也別掉以輕心。switch的case里如果用Integer底層會自動拆箱。一旦這個(gè)值是從Map里拿到的null照樣會空指針。同樣的邏輯也適用三目運(yùn)算符因?yàn)槿窟\(yùn)算符涉及類型推斷Integer和int混用時(shí)的拆箱行為經(jīng)常讓人踩坑。第四泛型嵌套別濫用通配符。新手很容易寫出ListList? extends Number這種嵌套通配符讀起來費(fèi)勁編譯期還可能給出莫名其妙的推斷錯(cuò)誤。大多數(shù)情況下直接寫ListListInteger就夠用了別為了通用而通配。第五重載方法時(shí)小心泛型的不可區(qū)分陷阱。比如void method(ListString list) {} void method(ListInteger list) {}這兩個(gè)方法同時(shí)存在會編譯報(bào)錯(cuò)因?yàn)椴脸蠛灻际莢oid method(List)。如果你需要在運(yùn)行時(shí)區(qū)分不同的泛型集合類型別指望方法重載要么加個(gè)Class?參數(shù)區(qū)分要么換不同的方法名。我在實(shí)際項(xiàng)目里的體會是包裝類和泛型之所以容易出問題根源都在編譯期和運(yùn)行期的信息不對等包裝類的緩存讓你誤以為是安全的泛型的擦除讓你誤以為類型信息是存在的。想通這兩點(diǎn)很多問題一眼就能看穿。下次面試官再問Integer緩存或者類型擦除你完全可以不只答背下來的結(jié)論而是從字節(jié)碼和JVM的角度給他講清楚背后的設(shè)計(jì)邏輯——這比背八股文要有說服力得多。