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