這個(gè)系列的第三篇本來(lái)想按老規(guī)矩把八股文再捋一遍結(jié)果整理目錄的時(shí)候發(fā)現(xiàn)大家問(wèn)得最多的往往不是某個(gè)知識(shí)點(diǎn)本身而是幾個(gè)特別容易翻車的運(yùn)行時(shí)環(huán)境和常見(jiàn)報(bào)錯(cuò)。比如有人分不清NoClassDefFoundError和ClassNotFoundException有人被Lombok的編譯器警告卡了一下午還有人用RedisTemplate做自增統(tǒng)計(jì)結(jié)果Redis返回“value is not an integer or out of range”。所以這一篇我不打算只堆面試題而是把這些真實(shí)場(chǎng)景揉進(jìn)去講清楚底層邏輯。適合正在準(zhǔn)備Java面試的朋友也適合剛?cè)胄邢胂到y(tǒng)補(bǔ)一遍基礎(chǔ)、想弄明白“為什么”而不是“是什么”的同學(xué)。內(nèi)容上我會(huì)從集合框架的底層原理講起再聊異常處理、JVM基礎(chǔ)、多線程這幾個(gè)大塊最后補(bǔ)充幾個(gè)高頻報(bào)錯(cuò)排查和一個(gè)很多人忽略的環(huán)境變量問(wèn)題。每部分都會(huì)配上我實(shí)際踩過(guò)的坑和面試官真正想聽(tīng)的回答思路。1. 集合框架面試官最愛(ài)問(wèn)的底層原理和擴(kuò)容細(xì)節(jié)集合這部分幾乎是每一場(chǎng)Java面試的必考題但很多人栽在同一個(gè)地方背了HashMap是數(shù)組加鏈表、默認(rèn)容量16、負(fù)載因子0.75卻解釋不清為什么要這么設(shè)計(jì)。面試官一旦追問(wèn)“為什么是0.75而不是0.5或者1.0”場(chǎng)面經(jīng)常冷下來(lái)。這一節(jié)我把幾個(gè)最核心的點(diǎn)拆開(kāi)講。1.1 HashMap的存儲(chǔ)邏輯從hash到紅黑樹(shù)HashMap的底層結(jié)構(gòu)在JDK 1.8之后是“數(shù)組 鏈表 紅黑樹(shù)”。當(dāng)你往里面put一個(gè)鍵值對(duì)時(shí)第一步是計(jì)算key的hash值然后把hash的高16位和低16位做異或處理。這個(gè)操作叫擾動(dòng)函數(shù)目的是讓高位信息也參與到低位計(jì)算中減少哈希碰撞的概率。第二步是用(n - 1) hash去定位數(shù)組下標(biāo)這里n是當(dāng)前數(shù)組長(zhǎng)度并且必須是2的冪。為什么要保證容量是2的冪因?yàn)?n - 1) hash等價(jià)于hash對(duì)n取模但位運(yùn)算比取模快得多。只有n是2的冪時(shí)n - 1的二進(jìn)制才會(huì)是全1的形態(tài)這樣低位才能完整保留hash的特征。所以就算你初始化時(shí)傳了一個(gè)不是2的冪的容量HashMap內(nèi)部也會(huì)通過(guò)tableSizeFor方法把它調(diào)整成最接近的2的冪。當(dāng)不同key算出來(lái)的下標(biāo)相同時(shí)鏈表的長(zhǎng)度就會(huì)增加當(dāng)鏈表長(zhǎng)度達(dá)到8且數(shù)組長(zhǎng)度達(dá)到64時(shí)鏈表會(huì)轉(zhuǎn)成紅黑樹(shù)。注意這里有兩個(gè)條件很多人只記了長(zhǎng)度8卻漏了數(shù)組長(zhǎng)度64導(dǎo)致代碼在特定場(chǎng)景下沒(méi)有觸發(fā)樹(shù)化排查半天找不到原因。至于為什么選8官方的注釋里給了一個(gè)泊松分布的參考數(shù)據(jù)簡(jiǎn)單理解就是正常情況下鏈表長(zhǎng)度達(dá)到8的概率極低低到可以用數(shù)學(xué)期望忽略不計(jì)所以8是一個(gè)時(shí)間和空間上都很平衡的閾值。1.2 擴(kuò)容機(jī)制與并發(fā)環(huán)境下的變化HashMap的默認(rèn)負(fù)載因子是0.75意思是當(dāng)元素個(gè)數(shù)超過(guò)容量 * 0.75時(shí)就要擴(kuò)容。這個(gè)值不是隨便定的太高會(huì)導(dǎo)致沖突增加、查詢變慢太低會(huì)浪費(fèi)空間0.75是官方在大量實(shí)驗(yàn)基礎(chǔ)上選出的一個(gè)折中值。擴(kuò)容時(shí)數(shù)組長(zhǎng)度翻倍所有元素需要重新計(jì)算下標(biāo)并搬移位置這個(gè)過(guò)程叫rehash。在JDK 1.7里并發(fā)put時(shí)擴(kuò)容可能產(chǎn)生環(huán)形鏈表導(dǎo)致get死循環(huán)這是老生常談的并發(fā)問(wèn)題。JDK 1.8改成尾插法后環(huán)形鏈表的問(wèn)題被解決了但這不代表HashMap能在并發(fā)環(huán)境下隨便用。并發(fā)put仍然會(huì)導(dǎo)致數(shù)據(jù)覆蓋、size不準(zhǔn)確等問(wèn)題。所以并發(fā)場(chǎng)景應(yīng)該用ConcurrentHashMap而不是在HashMap外面套一層synchronized。ConcurrentHashMap在JDK 1.8里已經(jīng)放棄了分段鎖的設(shè)計(jì)改為CAS加synchronized鎖的粒度從段細(xì)化到單個(gè)數(shù)組節(jié)點(diǎn)并發(fā)度大幅提升。面試時(shí)如果被問(wèn)到“ConcurrentHashMap怎么保證線程安全”核心回答是插入時(shí)對(duì)數(shù)組節(jié)點(diǎn)做CASCAS失敗再對(duì)鏈表頭節(jié)點(diǎn)加synchronized擴(kuò)容時(shí)用轉(zhuǎn)移節(jié)點(diǎn)協(xié)助多線程遷移。這個(gè)回答比單純說(shuō)“分段鎖”要高級(jí)也更貼合現(xiàn)在的版本。1.3 ArrayList擴(kuò)容與快速失敗機(jī)制ArrayList的擴(kuò)容邏輯比HashMap簡(jiǎn)單得多但依然是面試官喜歡挖細(xì)節(jié)的地方。默認(rèn)初始容量是10當(dāng)容量不夠時(shí)會(huì)擴(kuò)容為原來(lái)的1.5倍也就是oldCapacity (oldCapacity 1)。擴(kuò)容時(shí)會(huì)創(chuàng)建一個(gè)新數(shù)組再把舊元素復(fù)制過(guò)去這個(gè)過(guò)程如果發(fā)生在循環(huán)里性能損耗會(huì)非常大。所以如果提前能估算出元素?cái)?shù)量直接調(diào)用new ArrayList(預(yù)期大小)能省掉很多次擴(kuò)容拷貝?？焖偈C(jī)制也是集合框架的高頻考點(diǎn)。用ArrayList做遍歷時(shí)如果中途有另一個(gè)線程調(diào)用了add或remove迭代器會(huì)拋出ConcurrentModificationException。原理是迭代器內(nèi)部維護(hù)了一個(gè)modCount計(jì)數(shù)器每次結(jié)構(gòu)性修改都會(huì)讓modCount加一迭代器在讀取元素時(shí)會(huì)檢查當(dāng)前modCount是否和初始化時(shí)一致。這個(gè)機(jī)制解決不了并發(fā)一致性問(wèn)題只能“快速暴露問(wèn)題”它的名字fail-fast就是這個(gè)意思。真正的并發(fā)場(chǎng)景建議用CopyOnWriteArrayList它通過(guò)寫時(shí)復(fù)制來(lái)避免沖突適合讀多寫少的情況。2. 異常處理能把異常講明白的人不多異常這塊很多人以為背一下Exception和Error的區(qū)別就夠了但實(shí)際面試中面試官更想聽(tīng)的是你怎么設(shè)計(jì)異常、怎么避免吞異常、怎么讓異常信息跨層傳遞時(shí)還保持可讀性。這也是項(xiàng)目代碼里最容易暴露水平的地方。2.1 Checked與Unchecked的邊界Java把異常分成兩大類編譯期異常Checked Exception和運(yùn)行期異常RuntimeException/Unchecked Exception。前者像IOException、SQLException編譯器強(qiáng)制你處理后者像NullPointerException、ArrayIndexOutOfBoundsException編譯器不提醒但運(yùn)行時(shí)會(huì)炸。很多人不理解為什么Spring的JdbcTemplate要把SQLException翻譯成DataAccessException其實(shí)就是為了把受檢異常變成不受檢異常。受檢異常強(qiáng)制的catch或者throws會(huì)嚴(yán)重侵入業(yè)務(wù)代碼讓每一層方法簽名都帶著“throws SQLException”而且底層異常細(xì)節(jié)暴露給上層并不安全。Spring的翻譯思路是統(tǒng)一異常體系讓業(yè)務(wù)層只需要關(guān)心自己期望處理的異常其他的一路向上拋?zhàn)詈笥扇之惓Ｌ幚砥鞫档住?.2 try-with-resources和finally的取舍我見(jiàn)過(guò)很多老代碼用finally來(lái)關(guān)閉流寫法大概是先判斷非空再調(diào)用close還要在catch里處理close的異常。這種寫法最大的問(wèn)題是如果try塊里拋出異常同時(shí)close也拋出異常close的異常會(huì)覆蓋原始異常導(dǎo)致真正的問(wèn)題被掩蓋。JDK 7引人的try-with-resources就是用來(lái)解決這個(gè)問(wèn)題的。只要資源實(shí)現(xiàn)了AutoCloseable接口就可以寫在try后面的括號(hào)里程序結(jié)束時(shí)會(huì)自動(dòng)close。當(dāng)你既有關(guān)閉異常又有業(yè)務(wù)異常時(shí)JVM會(huì)把業(yè)務(wù)異常設(shè)為原始異常關(guān)閉異常作為被抑制異常保存下來(lái)可以通過(guò)getSuppressed()查看。這個(gè)細(xì)節(jié)很能體現(xiàn)一個(gè)人的基本功面試時(shí)主動(dòng)提到它效果比單純說(shuō)“try-with-resources可以自動(dòng)關(guān)流”好得多。try (BufferedReader reader new BufferedReader(new FileReader(test.txt))) { String line reader.readLine(); // 業(yè)務(wù)處理 } catch (IOException e) { // 這里拿到的異常信息是完整的不會(huì)因?yàn)殛P(guān)閉失敗被覆蓋 log.error(讀取文件失敗, e); }2.3 異常設(shè)計(jì)包裝、傳遞與日志的平衡很多人寫代碼喜歡在每個(gè)方法里catch異常然后log一遍等最后排查問(wèn)題時(shí)發(fā)現(xiàn)日志里打出十幾條一模一樣的堆棧根本不知道源頭在哪。我個(gè)人的習(xí)慣是底層方法不catch除非你確實(shí)有辦法處理需要跨層傳遞時(shí)用自定義異常包裝但一定要保留原始異常作為cause否則堆棧信息會(huì)斷掉。常見(jiàn)的技術(shù)面試題“什么是異常鏈”考察的就是這個(gè)。異常鏈就是異常從底層一層層向上拋時(shí)每一層都用new BusinessException(xxx, e)這種方式把原始異常掛在后面最終在最外層能看到完整的調(diào)用鏈而不是只剩一句“系統(tǒng)繁忙”。還有一點(diǎn)很多人會(huì)忽略不要catch了異常后什么都不做。哪怕只是log.debug一下也比完全吞掉強(qiáng)。但更忌諱的是catch里打日志然后又throw一個(gè)不包含原始異常的新異常這樣既打了兩遍日志又丟掉了最關(guān)鍵的底層細(xì)節(jié)。我在code review時(shí)看到這種寫法基本都會(huì)讓改掉。3. JVM與類加載基礎(chǔ)中的基礎(chǔ)JVM相關(guān)的題目在面試中出現(xiàn)的概率極高但很多人只是在背概念比如“堆存對(duì)象、棧存引用、方法區(qū)存類信息”真被問(wèn)到具體場(chǎng)景就答不上來(lái)了。這里我不打算把《深入理解Java虛擬機(jī)》全書復(fù)述一遍只挑幾個(gè)面試和日常排查中用得最多的點(diǎn)。3.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)的分工與常見(jiàn)誤解JVM的運(yùn)行時(shí)數(shù)據(jù)區(qū)可以簡(jiǎn)單分成五塊程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法棧、堆、方法區(qū)。程序計(jì)數(shù)器是唯一不會(huì)OOM的區(qū)域用來(lái)記錄當(dāng)前線程執(zhí)行到哪一行字節(jié)碼。虛擬機(jī)棧對(duì)應(yīng)每個(gè)線程每調(diào)用一個(gè)方法就會(huì)壓入一個(gè)棧幀棧幀里有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口。很多人以為“局部變量都存棧上”其實(shí)嚴(yán)格來(lái)說(shuō)棧里存的是基本類型變量和引用類型變量的引用對(duì)象本身在堆里。方法區(qū)在JDK 8之后被“元空間”取代它的一個(gè)重要變化是字符串常量池移動(dòng)到了堆中而類的元數(shù)據(jù)、運(yùn)行時(shí)常量池等仍然在元空間。這導(dǎo)致一個(gè)很經(jīng)典的問(wèn)題為什么JDK 7之后String.intern()的結(jié)果和之前不一樣。因?yàn)樽址Ａ砍卦谟谰么鷷r(shí)你可以設(shè)置-XX:MaxPermSize觸發(fā)PermGen OOM移到堆之后字符串常量池被普通堆管理頻繁intern大量字符串就會(huì)變成堆內(nèi)存的問(wèn)題。3.2 類加載過(guò)程與雙親委派模型類加載分成加載、驗(yàn)證、準(zhǔn)備、解析、初始化五個(gè)階段面試中常問(wèn)的是準(zhǔn)備階段和初始化階段的區(qū)別準(zhǔn)備階段會(huì)為靜態(tài)變量分配內(nèi)存并設(shè)置默認(rèn)值比如static int a 10這個(gè)階段a的值是0真正賦值為10要等到初始化階段因?yàn)槌跏蓟A段才執(zhí)行clinit方法。雙親委派模型建議用一句話概括一個(gè)類加載器收到加載請(qǐng)求時(shí)先不自己加載而是把請(qǐng)求委派給父加載器每一層都這樣做直到父加載器無(wú)法加載時(shí)才由自己加載。這樣做的目的有兩個(gè)第一是防止核心API被篡改比如你自定義一個(gè)java.lang.String類加載時(shí)會(huì)先讓Bootstrap ClassLoader去加載rt.jar里的String你的實(shí)現(xiàn)根本沒(méi)機(jī)會(huì)生效第二是避免類重復(fù)加載同一個(gè)類不會(huì)出現(xiàn)兩份不同的字節(jié)碼。很多框架整合時(shí)會(huì)打破雙親委派比如Tomcat為了隔離不同web應(yīng)用會(huì)自己先加載WebApp下的類。這個(gè)問(wèn)題如果被問(wèn)到“為什么要打破雙親委派”可以從容器隔離和熱部署的角度回答。3.3 一次NoClassDefFoundError的排查實(shí)錄NoClassDefFoundError是我工作中遇到頻率最高的類加載問(wèn)題之一。很多人把它和ClassNotFoundException混在一起其實(shí)兩者完全不一樣。ClassNotFoundException是顯式調(diào)用Class.forName或ClassLoader.loadClass時(shí)類路徑下壓根找不到對(duì)應(yīng)的類文件屬于被檢查的異常而NoClassDefFoundError是編譯期這個(gè)類存在運(yùn)行時(shí)JVM在加載其他類時(shí)發(fā)現(xiàn)某個(gè)依賴類缺失或者某個(gè)靜態(tài)初始化塊拋了異常導(dǎo)致類加載失敗。我遇到過(guò)最典型的一個(gè)場(chǎng)景是老項(xiàng)目里有一段代碼引用了java.applet.AppletJDK 8下跑得好好的升級(jí)到JDK 9以后啟動(dòng)直接報(bào)Uncaught exception java.lang.NoClassDefFoundError: java/applet/Applet。原因是JDK 9引入模塊化之后Applet相關(guān)API被從默認(rèn)的java.se模塊中移除了老代碼在運(yùn)行時(shí)找不到這個(gè)類于是拋出NoClassDefFoundError但很多人第一反應(yīng)是去項(xiàng)目里找這個(gè)類怎么也找不到因?yàn)閱?wèn)題根源在JDK版本兼容性上。排查順序建議是先看完整堆棧確定哪個(gè)類加載失敗再用jdeps檢查項(xiàng)目依賴?yán)锏腏AR是否引用了已移除的API然后確認(rèn)JDK版本和項(xiàng)目編譯版本是否一致。如果是生產(chǎn)環(huán)境千萬(wàn)不要直接升級(jí)JDK版本就完事要結(jié)合項(xiàng)目的第三方依賴逐一驗(yàn)證。4. 多線程與并發(fā)高并發(fā)面試的敲門磚多線程是Java基礎(chǔ)里最龐雜的一塊從Thread到synchronized、volatile、Lock、ThreadLocal、線程池每一個(gè)都能往外延伸出大量問(wèn)題。這一節(jié)我只挑三個(gè)最核心的考點(diǎn)synchronized的底層機(jī)制、volatile的作用、線程池的參數(shù)執(zhí)行邏輯。4.1 synchronized的三種用法和鎖升級(jí)過(guò)程synchronized是Java內(nèi)置的關(guān)鍵字可以用來(lái)修飾實(shí)例方法、靜態(tài)方法和代碼塊。修飾實(shí)例方法時(shí)鎖的是當(dāng)前實(shí)例對(duì)象修飾靜態(tài)方法時(shí)鎖的是當(dāng)前類的Class對(duì)象修飾代碼塊時(shí)鎖的是括號(hào)里指定的對(duì)象。JDK 6之后synchronized做了大量?jī)?yōu)化引入了偏向鎖、輕量級(jí)鎖、重量級(jí)鎖的升級(jí)過(guò)程。簡(jiǎn)單記憶剛開(kāi)始無(wú)競(jìng)爭(zhēng)時(shí)是偏向鎖只有一個(gè)線程反復(fù)進(jìn)入同步塊鎖會(huì)記錄這個(gè)線程的ID避免每次加鎖都走CAS當(dāng)有另一個(gè)線程來(lái)競(jìng)爭(zhēng)時(shí)偏向鎖撤銷并升級(jí)為輕量級(jí)鎖輕量級(jí)鎖用CAS和自旋來(lái)獲取鎖適合鎖持有時(shí)間很短的場(chǎng)景競(jìng)爭(zhēng)進(jìn)一步加劇時(shí)就升級(jí)為重量級(jí)鎖也就是依賴操作系統(tǒng)的互斥量此時(shí)線程會(huì)被掛起和喚醒性能消耗最大。面試官追問(wèn)“為什么重量級(jí)鎖慢”你要能答出因?yàn)樯婕坝脩魬B(tài)和內(nèi)核態(tài)的切換。這是操作系統(tǒng)層面的開(kāi)銷不是JVM能控制的所以高并發(fā)場(chǎng)景下要盡量減少synchronized持有時(shí)間。4.2 volatile的可見(jiàn)性和禁止重排序volatile是最容易被誤解的關(guān)鍵字。它的兩個(gè)核心作用保證變量的可見(jiàn)性以及禁止指令重排序。它并不保證原子性比如volatile int count多個(gè)線程執(zhí)行count依然會(huì)丟數(shù)據(jù)因?yàn)閏ount在字節(jié)碼層面是讀、加、寫三步操作不是原子的?？梢?jiàn)性的底層原理是對(duì)一個(gè)volatile變量執(zhí)行寫操作時(shí)JVM會(huì)插入內(nèi)存屏障強(qiáng)制把當(dāng)前線程工作內(nèi)存中的變量值刷新到主內(nèi)存讀操作時(shí)會(huì)讓其他線程工作內(nèi)存中的該變量失效必須重新從主內(nèi)存讀取。禁止重排序的作用則主要體現(xiàn)在單例模式的雙重檢查鎖里public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }如果不加volatileinstance new Singleton()這行代碼在CPU級(jí)別的執(zhí)行順序可能被重排成先分配內(nèi)存、賦值給引用、再執(zhí)行構(gòu)造函數(shù)。如果另一個(gè)線程在構(gòu)造函數(shù)執(zhí)行完之前讀到了非空的instance就會(huì)拿到一個(gè)構(gòu)造不完整的對(duì)象。但這又和“對(duì)象的半初始化”有關(guān)很多人只背結(jié)論不知道為什么我這里說(shuō)清楚加volatile就是告訴JVM引用賦值操作不能越過(guò)內(nèi)存屏障重排到構(gòu)造方法之前。4.3 線程池核心參數(shù)與執(zhí)行順序線程池是Java并發(fā)編程里實(shí)務(wù)性最強(qiáng)的一塊也是面試必問(wèn)。核心類ThreadPoolExecutor有七個(gè)參數(shù)很多人只記得corePoolSize、maximumPoolSize、workQueue但問(wèn)起執(zhí)行順序就亂了。正確的執(zhí)行邏輯是提交任務(wù)時(shí)如果當(dāng)前線程數(shù)小于核心線程數(shù)創(chuàng)建新線程執(zhí)行如果當(dāng)前線程數(shù)已經(jīng)達(dá)到核心線程數(shù)任務(wù)進(jìn)入阻塞隊(duì)列等待如果阻塞隊(duì)列也滿了當(dāng)前線程數(shù)小于最大線程數(shù)創(chuàng)建非核心線程執(zhí)行如果當(dāng)前線程數(shù)已經(jīng)達(dá)到最大線程數(shù)執(zhí)行拒絕策略。這里最容易被繞暈的是“隊(duì)列滿才創(chuàng)建新線程”而不是“核心線程和最大線程之間還差多少就補(bǔ)多少”。keepAliveTime針對(duì)的是非核心線程空閑超過(guò)這個(gè)時(shí)間就會(huì)被回收unit是時(shí)間單位threadFactory用來(lái)定制線程名和是否守護(hù)線程handler是拒絕策略。拒絕策略一共有四種AbortPolicy直接拋異常是默認(rèn)策略CallerRunsPolicy由提交任務(wù)的線程自己執(zhí)行適合不想丟失任務(wù)的場(chǎng)景DiscardPolicy默默丟棄DiscardOldestPolicy丟棄隊(duì)列里最舊的任務(wù)然后重新嘗試提交。5. 幾個(gè)特別容易翻車的運(yùn)行時(shí)問(wèn)題排查實(shí)錄從搜索熱詞里可以看出現(xiàn)在很多人搜Java基礎(chǔ)題已經(jīng)不局限于“什么是繼承、什么是多態(tài)”這種純概念題了更多的困擾來(lái)自實(shí)際運(yùn)行時(shí)報(bào)錯(cuò)。這一節(jié)我專門挑三個(gè)近期高頻出現(xiàn)的問(wèn)題來(lái)寫。5.1 Lombok編譯警告You arent using a compiler supported by lombok這個(gè)報(bào)錯(cuò)我最近看到特別多完整提示是java: You arent using a compiler supported by lombok, so lombok will not work with your project。出現(xiàn)這個(gè)問(wèn)題的原因通常是你使用的JDK版本比較新而項(xiàng)目里引入的Lombok版本太老Lombok的注解處理器還不認(rèn)識(shí)當(dāng)前JDK的編譯器。解決方式分三步第一把Lombok升級(jí)到支持對(duì)應(yīng)JDK的版本比如JDK 16以上推薦1.18.20JDK 21推薦1.18.30第二在IDE里確認(rèn)安裝了Lombok插件并開(kāi)啟Annotation ProcessingIDEA里位置在Settings - Build - Compiler - Annotation Processors勾選Enable annotation processing第三檢查Maven或Gradle依賴?yán)锸欠襁€有舊的Lombok傳遞依賴被帶進(jìn)來(lái)最好用mvn dependency:tree看一下。這個(gè)報(bào)錯(cuò)還有一個(gè)坑有時(shí)候升級(jí)了Lombok還是報(bào)錯(cuò)但錯(cuò)誤信息來(lái)自Maven編譯階段那就要檢查pom.xml里Maven Compiler Plugin的source和target版本是不是和JDK版本不匹配。比如用JDK 17編譯卻把source/target設(shè)為1.8某些注解處理路徑會(huì)出現(xiàn)怪異問(wèn)題。5.2 RedisTemplate調(diào)用increment()value is not an integer or out of range有人用RedisTemplateString, Object去執(zhí)行redisTemplate.opsForValue().increment(key)結(jié)果Redis報(bào)ERR value is not an integer or out of range。這個(gè)問(wèn)題看著像value格式不對(duì)實(shí)際原因往往是序列化器的問(wèn)題。RedisTemplate默認(rèn)用的是JdkSerializationRedisSerializerkey和value都會(huì)經(jīng)過(guò)Java序列化。序列化之后字符串類型的key在Redis里存的是帶二進(jìn)制頭部信息的東西當(dāng)你對(duì)同一個(gè)key執(zhí)行INCR命令時(shí)Redis端看到的是一個(gè)字節(jié)數(shù)組不是整數(shù)于是直接拒絕。而StringRedisTemplate默認(rèn)用StringRedisSerializervalue以明文字符串存儲(chǔ)Redis才能正確解析為整數(shù)。解決方式有兩種第一如果不需要復(fù)雜對(duì)象直接用StringRedisTemplate來(lái)執(zhí)行increment第二如果要用RedisTemplate把key和value的序列化器都改成StringRedisSerializer。我習(xí)慣在配置類里統(tǒng)一初始化一個(gè)RedisTemplate Bean專門指定key和hashKey用String序列化器這樣能避開(kāi)大部分誤用問(wèn)題。5.3 Java 8的lambda三個(gè)容易讓人懵的細(xì)節(jié)lambda表達(dá)式是Java 8引入后最常用的新特性但使用中還是有幾個(gè)細(xì)節(jié)經(jīng)常被問(wèn)到。第一lambda表達(dá)式里引用的外部局部變量必須是effectively final也就是變量值一旦賦值就不能再修改。這個(gè)限制的主要原因是lambda本質(zhì)上是一個(gè)匿名內(nèi)部類它捕獲外部變量時(shí)是通過(guò)方法參數(shù)傳遞的副本而不是直接操作原始變量。既然操作的是副本就必須保證原始變量永遠(yuǎn)不會(huì)變化否則語(yǔ)義就亂了。第二lambda里處理受檢異常很別扭。如果你在lambda體里調(diào)一個(gè)會(huì)拋IOException的方法編譯器會(huì)要求你用try-catch包起來(lái)因?yàn)镽unnable和Function這類函數(shù)式接口的方法聲明不包含throws。解決辦法是包裝成自定義的Unchecked函數(shù)式接口或者直接在lambda內(nèi)部try-catch然后轉(zhuǎn)成RuntimeException拋出。第三stream的peek方法不是forEach。peek是中間操作它不會(huì)觸發(fā)流的遍歷只有遇到終止操作如collect、forEach時(shí)才會(huì)執(zhí)行。很多人調(diào)試時(shí)想在peek里打印一些信息結(jié)果發(fā)現(xiàn)不打印以為代碼沒(méi)執(zhí)行其實(shí)項(xiàng)目里沒(méi)有觸發(fā)流消費(fèi)。6. 手寫題與機(jī)制題冒泡排序和動(dòng)態(tài)代理這類代碼題怎么答現(xiàn)在的Java面試特別是一線大廠越來(lái)越喜歡讓候選人現(xiàn)場(chǎng)手寫代碼而且不滿足于“能寫出來(lái)”還要追問(wèn)優(yōu)化和底層機(jī)制。這里挑兩個(gè)高頻例子展開(kāi)。6.1 冒泡排序能寫出優(yōu)化版本才是加分項(xiàng)冒泡排序幾乎是所有面試準(zhǔn)備者都會(huì)背的算法但真正被問(wèn)到時(shí)很多人只寫了最原始的版本完全沒(méi)有體現(xiàn)優(yōu)化意識(shí)。最早的冒泡排序版本是這樣的public static void bubbleSort(int[] arr) { for (int i 0; i arr.length - 1; i) { for (int j 0; j arr.length - 1 - i; j) { if (arr[j] arr[j 1]) { int tmp arr[j]; arr[j] arr[j 1]; arr[j 1] tmp; } } } }優(yōu)化點(diǎn)至少有兩個(gè)。第一每輪結(jié)束后如果發(fā)現(xiàn)沒(méi)有任何交換說(shuō)明數(shù)組已經(jīng)有序可以直接break。第二記錄最后一輪發(fā)生交換的位置這個(gè)位置之后的元素已經(jīng)有序下一輪只需要遍歷到這個(gè)位置之前。這兩種優(yōu)化在隨機(jī)大數(shù)組上雖然改變不了O(n2)的時(shí)間復(fù)雜度但在近乎有序的數(shù)據(jù)上性能提升非常明顯。面試時(shí)主動(dòng)寫出這兩點(diǎn)比背十道LeetCode印象更深。6.2 動(dòng)態(tài)代理JDK代理與CGLIB的本質(zhì)差異動(dòng)態(tài)代理是Spring AOP的底層基礎(chǔ)也是Java核心機(jī)制里被問(wèn)到“繞不開(kāi)”的題。很多人只會(huì)說(shuō)“JDK動(dòng)態(tài)代理基于接口CGLIB基于繼承”但再往下問(wèn)“為什么Spring Boot默認(rèn)用CGLIB”就卡住了。JDK動(dòng)態(tài)代理的用法是實(shí)現(xiàn)InvocationHandler接口通過(guò)Proxy.newProxyInstance生成代理對(duì)象。它生成的代理類已經(jīng)實(shí)現(xiàn)了目標(biāo)接口所以只能代理接口類型。如果你的業(yè)務(wù)類沒(méi)有實(shí)現(xiàn)任何接口JDK代理就無(wú)能為力。CGLIB的原理是生成目標(biāo)類的子類通過(guò)繼承來(lái)代理方法調(diào)用。因?yàn)樗玫氖抢^承所以final方法不能被代理final類也不能被代理。Spring在早期版本里如果目標(biāo)對(duì)象實(shí)現(xiàn)了接口就優(yōu)先用JDK代理否則用CGLIBSpring Boot 2.x之后默認(rèn)就改成CGLIB了因?yàn)镃GLIB的性能在近幾個(gè)版本已經(jīng)追平甚至超過(guò)JDK代理而且不需要強(qiáng)制要求業(yè)務(wù)類實(shí)現(xiàn)接口使用起來(lái)更省心。面試時(shí)如果能補(bǔ)一句“JDK代理每次調(diào)用要走InvocationHandler的invokeCGLIB通過(guò)FastClass機(jī)制緩存方法索引調(diào)用效率更高”會(huì)顯得你真的研究過(guò)機(jī)制而不是只背結(jié)論。6.3 雙檢鎖與枚舉單例手寫單例的擴(kuò)展點(diǎn)手寫單例也是面試高頻題。最簡(jiǎn)單的寫法是餓漢式但考慮到懶加載很多人會(huì)寫雙重檢查鎖。這部分已經(jīng)在volatile小節(jié)講過(guò)但面試官還喜歡追問(wèn)“為什么不用synchronized修飾整個(gè)getInstance方法”。答案是鎖的粒度太大每次調(diào)用都會(huì)串行執(zhí)行性能損耗嚴(yán)重。雙檢鎖只是在實(shí)例為空的時(shí)候加鎖初始化完成后再進(jìn)來(lái)就直接返回已有的對(duì)象。還有一個(gè)冷門的考點(diǎn)是用枚舉實(shí)現(xiàn)單例。enum Singleton { INSTANCE }這種寫法天然線程安全而且可以防止反序列化破壞單例。大多數(shù)人在項(xiàng)目里不會(huì)真的這樣寫但面試時(shí)能提出來(lái)說(shuō)明你對(duì)單例的各種實(shí)現(xiàn)方式都有過(guò)思考。7. 環(huán)境變量配置與八股文之外的復(fù)習(xí)建議寫到最后這一節(jié)想聊一件看起來(lái)很小、但很多人會(huì)卡住的事情Java環(huán)境變量配置。別笑這個(gè)真的經(jīng)常出現(xiàn)在搜索熱詞里。很多人裝完JDK第一時(shí)間就去改環(huán)境變量結(jié)果怎么配都不對(duì)。7.1 JAVA_HOME、PATH和CLASSPATH的角色環(huán)境變量配置只需要三步先確認(rèn)JDK安裝目錄然后在系統(tǒng)變量里新建JAVA_HOME值為JDK安裝路徑比如C:\Program Files\Java\jdk-17接著在PATH變量里新增%JAVA_HOME%\bin最后打開(kāi)新終端執(zhí)行java -version驗(yàn)證。這里有兩個(gè)常見(jiàn)誤區(qū)第一是只配了PATH沒(méi)配JAVA_HOME導(dǎo)致很多基于Java的中間件找不到JDK第二是還要配CLASSPATH這個(gè)變量在JDK 9之后已經(jīng)基本沒(méi)有配置的必要了舊教程里讓人配CLASSPATH.;%JAVA_HOME%\lib那是早期版本為了找dt.jar和tools.jar的遺留做法現(xiàn)在再配反而可能引發(fā)類加載問(wèn)題。注意修改完環(huán)境變量后一定要新開(kāi)一個(gè)命令行窗口再執(zhí)行java -version因?yàn)橐呀?jīng)打開(kāi)的控制臺(tái)不會(huì)自動(dòng)刷新環(huán)境變量。這個(gè)問(wèn)題我見(jiàn)過(guò)太多次不是沒(méi)配好是沒(méi)刷新。7.2 從八股文到實(shí)戰(zhàn)面試怎么準(zhǔn)備才算有效關(guān)于“Java基礎(chǔ)面試題”和“Java面試八股文”這類搜索詞我的看法是八股文可以背但不能只靠背。面試官現(xiàn)在問(wèn)問(wèn)題的方式早就變了同樣的知識(shí)點(diǎn)他會(huì)包裝在場(chǎng)景里問(wèn)你。比如不直接問(wèn)“HashMap和Hashtable有什么區(qū)別”而是問(wèn)你“有一萬(wàn)次并發(fā)寫操作該用哪個(gè)集合”這時(shí)候你就要能聯(lián)想到ConcurrentHashMap的CAS加synchronized設(shè)計(jì)。我自己準(zhǔn)備面試時(shí)的習(xí)慣是每看到一個(gè)知識(shí)點(diǎn)就問(wèn)自己三個(gè)問(wèn)題——它解決什么問(wèn)題不解決什么問(wèn)題底層是怎么實(shí)現(xiàn)的比如看到volatile就接著想原子性怎么解決、什么時(shí)候會(huì)用到它、內(nèi)存屏障是什么。這樣把一個(gè)知識(shí)點(diǎn)往外擴(kuò)一圈面試時(shí)不管怎么追問(wèn)都能接住。這個(gè)系列整理到第三篇我最大的感受是Java基礎(chǔ)看著知識(shí)點(diǎn)多其實(shí)脈絡(luò)很清晰核心就是集合、異常、JVM、多線程外加幾個(gè)高頻框架機(jī)制。把這些基礎(chǔ)吃透了面試和日常開(kāi)發(fā)都能穩(wěn)不少。最后再分享一個(gè)小技巧復(fù)習(xí)時(shí)準(zhǔn)備一個(gè)自己的報(bào)錯(cuò)記錄文檔遇到NoClassDefFoundError、increment()報(bào)錯(cuò)這類問(wèn)題就寫進(jìn)去時(shí)間長(zhǎng)了你會(huì)發(fā)現(xiàn)面試官問(wèn)的很多問(wèn)題其實(shí)都是你踩過(guò)的坑的變體。