境配置、核心API、異常排查與算法原理)
這一篇是Java基礎(chǔ)常見(jiàn)問(wèn)題系列的第三篇。前面兩篇聊了不少語(yǔ)法細(xì)節(jié)和集合框架的坑結(jié)果后臺(tái)收到最多的留言反而是“環(huán)境配置翻車”“報(bào)錯(cuò)看不懂”“面試被問(wèn)住”這幾類。所以這篇我換個(gè)思路不再按語(yǔ)法書(shū)目錄走而是把熱搜詞里大家真正高頻搜索的問(wèn)題挑出來(lái)分成環(huán)境與編譯期、核心API、異常排查、面試與算法四個(gè)板塊逐個(gè)拆開(kāi)揉碎講清楚。不管你是剛裝好JDK準(zhǔn)備寫第一個(gè)Hello World還是工作兩三年后回頭補(bǔ)基礎(chǔ)這篇都適合花二十分鐘認(rèn)真過(guò)一遍。所有問(wèn)題都是實(shí)際開(kāi)發(fā)里真會(huì)遇到的每一條背后都有可復(fù)現(xiàn)的報(bào)錯(cuò)信息或者可驗(yàn)證的代碼看完能直接用不是那種背完就忘的八股問(wèn)答。1. 環(huán)境與編譯期問(wèn)題裝對(duì)JDK只是開(kāi)始1.1 JAVA_HOME與PATH為什么配了環(huán)境變量還是報(bào)錯(cuò)很多新手第一次裝JDK網(wǎng)上搜了一篇教程照著配完環(huán)境變量打開(kāi)命令行敲java -version有輸出以為就萬(wàn)事大吉了。結(jié)果沒(méi)過(guò)多久用IDEA建項(xiàng)目時(shí)提示找不到JDK或者寫了一個(gè)啟動(dòng)腳本雙擊運(yùn)行直接報(bào)錯(cuò)這時(shí)候才發(fā)現(xiàn)環(huán)境變量沒(méi)那么簡(jiǎn)單。先搞清楚JAVA_HOME和PATH各自是干什么的。JAVA_HOME是一個(gè)自定義變量它指向JDK的安裝根目錄比如C:\Program Files\Java\jdk-17。JDK本身以及Tomcat、Maven、Gradle這些工具啟動(dòng)時(shí)都要靠這個(gè)變量找到JDK的位置。而PATH是系統(tǒng)用來(lái)找可執(zhí)行文件的路徑集合你在命令行里敲java系統(tǒng)會(huì)按順序遍歷PATH列出的每個(gè)目錄找到名為java.exe的文件就執(zhí)行。所以PATH里必須包含%JAVA_HOME%\bin否則系統(tǒng)找不到j(luò)ava命令。配完了還報(bào)錯(cuò)最常見(jiàn)的原因有三個(gè)。第一個(gè)是PATH的系統(tǒng)變量和用戶變量沖突。Windows系統(tǒng)的環(huán)境變量分“用戶變量”和“系統(tǒng)變量”兩欄兩者最終會(huì)合并生效但順序上有講究用戶變量在前系統(tǒng)變量在后。如果你在用戶變量里配了一個(gè)舊版本JDK的路徑又在系統(tǒng)變量里配了新版JDK最后生效的可能是用戶變量里那個(gè)舊的。解決辦法很簡(jiǎn)單打開(kāi)命令行執(zhí)行where java它會(huì)列出所有找到的java.exe及其路徑一眼就能看出實(shí)際用的是哪個(gè)。第二個(gè)是變量順序問(wèn)題。有人把JAVA_HOME刪了直接在PATH里寫死絕對(duì)路徑C:\Program Files\Java\jdk-17\bin這樣單獨(dú)看沒(méi)問(wèn)題。但你日后升級(jí)JDK版本比如從17升到21就得再改一遍PATH而且如果你裝了多個(gè)JDK或者有其他軟件往PATH里塞了Java路徑就很容易亂。標(biāo)準(zhǔn)做法還是先設(shè)置JAVA_HOME然后PATH里寫%JAVA_HOME%\bin這樣以后切版本只改JAVA_HOME一處。第三個(gè)是配置了但沒(méi)生效。環(huán)境變量修改后已經(jīng)打開(kāi)的命令行窗口不會(huì)自動(dòng)刷新需要重開(kāi)一個(gè)新的命令行窗口。IDEA如果是在修改之前啟動(dòng)的也要重啟IDEA。這個(gè)原因最蠢也最容易踩。再補(bǔ)充一個(gè)高頻場(chǎng)景本機(jī)裝了多個(gè)JDK比如一個(gè)8用在老項(xiàng)目一個(gè)17用在新項(xiàng)目。這時(shí)候只靠改JAVA_HOME來(lái)實(shí)現(xiàn)切換并不總是有效因?yàn)镻ATH里如果存在JDK8自帶的jre路徑或者之前裝過(guò)Oracle官網(wǎng)版的Java注冊(cè)表里也留了版本信息某些軟件會(huì)去讀注冊(cè)表而不是讀JAVA_HOME。我的建議是日常開(kāi)發(fā)統(tǒng)一用JAVA_HOME切換必要時(shí)配合where java驗(yàn)證如果真的需要頻繁切換并希望更省心可以借助開(kāi)源的sdkman或者Windows下的SDKMAN-like工具來(lái)管理多版本JDK不過(guò)基礎(chǔ)思路還是理解環(huán)境變量的優(yōu)先級(jí)。1.2 Lombok與編譯器版本沖突一句話背后的連鎖反應(yīng)這兩年JDK的發(fā)布節(jié)奏變成半年一個(gè)大版本很多團(tuán)隊(duì)還停在JDK8但總有喜歡追新的人把開(kāi)發(fā)環(huán)境的JDK升到了17、21甚至更新。升完JDK之后一個(gè)高頻報(bào)錯(cuò)就出現(xiàn)了java: you arent using a compiler supported by lombok, so lombok will not work.這句話從字面看是“你用的編譯器Lombok不支持”但很多人不理解為什么javac換了個(gè)版本Lombok就罷工了。這里要交代一下Lombok的工作原理。Lombok不是普通的jar包它在編譯階段通過(guò)Java的注解處理器Annotation Processor機(jī)制介入編譯過(guò)程在抽象語(yǔ)法樹(shù)AST上做修改往類里注入getter、setter、builder等方法。JDK的編譯器javac內(nèi)部實(shí)現(xiàn)對(duì)Lombok來(lái)說(shuō)就是一套特定的APIJDK版本一變這張API就可能有變動(dòng)Lombok沒(méi)跟上就必須拒絕工作否則硬往AST里塞代碼指不定編譯出什么畸形字節(jié)碼。所以這個(gè)問(wèn)題的本質(zhì)是Lombok版本太老不支持當(dāng)前JDK版本。解決辦法也直接——升級(jí)Lombok。以Maven項(xiàng)目為例引入的依賴坐標(biāo)保持不變但版本號(hào)需要跟著JDK版本走dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId version1.18.36/version scopeprovided/scope /dependency以我的經(jīng)驗(yàn)JDK17用Lombok 1.18.20以上基本沒(méi)問(wèn)題JDK21建議直接用1.18.30以上再保守一點(diǎn)就選最新的release版本。Gradle項(xiàng)目的話在dependencies里同步調(diào)整版本即可。排查這個(gè)報(bào)錯(cuò)時(shí)還有幾個(gè)容易忽略的細(xì)節(jié)。我遇到過(guò)升級(jí)了Lombok版本、重啟了IDEA仍然報(bào)同樣錯(cuò)誤的情況后來(lái)發(fā)現(xiàn)是IDEA的Build選項(xiàng)里勾選了Delegate IDE build/run actions to Maven本質(zhì)上是Maven的編譯進(jìn)程還在用舊的注解處理器。這時(shí)候要執(zhí)行一次mvn clean compile看Maven是不是能正常編譯。如果Maven能過(guò)而IDEA不能過(guò)檢查IDEA的Settings → Build → Compiler → Annotation Processors是否勾選了Enable annotation processing。Lombok要在IDE里生效這一步必須打開(kāi)。注意有些項(xiàng)目會(huì)同時(shí)在pom.xml里顯式引入lombok-maven-plugin這個(gè)老插件只在少數(shù)場(chǎng)景有用絕大多數(shù)情況下不需要升級(jí)到新版IDE和Lombok版本就能解決。2. 核心API與常用類平時(shí)寫代碼最容易栽的地方2.1 String、StringBuilder、StringBuffer不只是“拼接效率”那點(diǎn)事Java面試?yán)颯tring相關(guān)的題永遠(yuǎn)不過(guò)時(shí)但很多人背了“String不可變、StringBuffer線程安全、StringBuilder線程不安全”就以為掌握全場(chǎng)了一上手寫代碼照樣掉坑。先說(shuō)一個(gè)最典型的錯(cuò)誤在循環(huán)里用拼接字符串。String result ; for (int i 0; i 10000; i) { result i ,; }這段代碼在語(yǔ)法上沒(méi)有任何問(wèn)題但性能很差。原因是String類是不可變的每次都會(huì)創(chuàng)建新的字符串對(duì)象舊的字符串對(duì)象變成垃圾等待回收。循環(huán)一萬(wàn)次就會(huì)創(chuàng)建一萬(wàn)個(gè)中間字符串對(duì)象。你可能說(shuō)編譯器不是會(huì)優(yōu)化成StringBuilder嗎確實(shí)javac會(huì)將單個(gè)表達(dá)式優(yōu)化成new StringBuilder().append()...toString()但這是在單條語(yǔ)句內(nèi)部跨循環(huán)迭代時(shí)每一次都會(huì)創(chuàng)建獨(dú)立的StringBuilder照樣有性能損耗。正確寫法是用StringBuilderStringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i).append(,); } String result sb.toString();這里.append(i).append(,)連續(xù)調(diào)用是StringBuilder的鏈?zhǔn)秸{(diào)用設(shè)計(jì)每步返回同一個(gè)對(duì)象從頭到尾只創(chuàng)建一個(gè)StringBuilder實(shí)例。至于StringBuffer它的所有公開(kāi)方法幾乎都加了synchronized所以在單線程環(huán)境下的性能比StringBuilder差多線程環(huán)境下兩個(gè)類也都不適合作為共享可變狀態(tài)來(lái)使用。換句話說(shuō)StringBuffer的“線程安全”在絕大多數(shù)場(chǎng)景是個(gè)偽需求。我在實(shí)際項(xiàng)目中基本只在一種情況用StringBuffer面試Demo里為了展示線程安全。日常開(kāi)發(fā)統(tǒng)一用StringBuilder就好。還有一個(gè)衍生問(wèn)題值得講為什么String設(shè)計(jì)成不可變網(wǎng)上答案很多我挑幾個(gè)關(guān)鍵的。第一字符串常量池需要靠不可變性來(lái)保證安全性同一個(gè)字符串字面量被多個(gè)變量引用如果其中一處修改了內(nèi)容其他引用就全亂了。第二作為HashMap的key不可變保證了hashCode的穩(wěn)定性如果key的hashCode變化HashMap就再也找不到這個(gè)鍵了。第三String對(duì)象會(huì)被網(wǎng)絡(luò)傳輸、文件讀寫大量使用不可變讓這些場(chǎng)景更安全避免意外修改。面試時(shí)如果被問(wèn)到“String可以繼承嗎”答案是不可以String是final的。這個(gè)設(shè)計(jì)不是為了防程序員而是為了確保字符串的不可變性和安全性不被破壞還有編譯器的各種優(yōu)化可以放心假設(shè)String對(duì)象的值不會(huì)變。2.2 包裝類緩存與equals比較100和1000的區(qū)別來(lái)看一段代碼Integer a 100; Integer b 100; System.out.println(a b); // true Integer c 1000; Integer d 1000; System.out.println(c d); // false同樣是用比較兩個(gè)Integer為什么一個(gè)輸出true一個(gè)輸出false原因是Java在Integer類內(nèi)部維護(hù)了一個(gè)緩存數(shù)組默認(rèn)緩存了-128到127之間的所有Integer對(duì)象。當(dāng)你通過(guò)自動(dòng)裝箱創(chuàng)建Integer對(duì)象時(shí)如果值在緩存范圍內(nèi)直接返回緩存中已有的同一個(gè)對(duì)象所以100 100是true。值超過(guò)127緩存中不存在就得新建對(duì)象所以1000 1000用了兩個(gè)不同對(duì)象比較的是引用地址自然是false。這個(gè)緩存機(jī)制在Java面試?yán)飵缀醣乜?。JDK的源碼里有個(gè)IntegerCache內(nèi)部類其中l(wèi)ow默認(rèn)-128high默認(rèn)127high可以通過(guò)啟動(dòng)參數(shù)-XX:AutoBoxCacheMax1000調(diào)大。除了Integer其他整數(shù)包裝類也有類似機(jī)制Byte、Short、Long緩存范圍固定為-128到127Character緩存0到127。浮點(diǎn)型Float、Double沒(méi)有緩存因?yàn)檎麛?shù)范圍內(nèi)的緩存數(shù)量有限而浮點(diǎn)數(shù)理論上無(wú)限?；谶@個(gè)原理開(kāi)發(fā)中用包裝對(duì)象做比較時(shí)必須記住一個(gè)規(guī)矩只要是比較兩個(gè)包裝類對(duì)象的值一律用equals()或者轉(zhuǎn)成基本類型再用。比如判斷兩個(gè)Integer是否相等寫成a.equals(b)或者a.intValue() b.intValue()。Java 7之后還可以用Objects.equals(a, b)內(nèi)部會(huì)做空指針判斷比a.equals(b)更嚴(yán)謹(jǐn)因?yàn)楹笳咴赼為null時(shí)直接空指針。再延伸一個(gè)相關(guān)知識(shí)點(diǎn)自動(dòng)裝箱Autoboxing和自動(dòng)拆箱Unboxing。Integer a 100本質(zhì)是Integer a Integer.valueOf(100)int x a本質(zhì)是x a.intValue()。在循環(huán)或者高頻運(yùn)算里如果反復(fù)在Integer和int之間轉(zhuǎn)換會(huì)額外產(chǎn)生對(duì)象創(chuàng)建的開(kāi)銷。比如寫Long sum 0L; for (long i 0; i 100000; i) { sum i; }由于sum是Long包裝類型每次sum i都要先拆箱成long做加法再裝箱回Long循環(huán)十萬(wàn)次就產(chǎn)生十萬(wàn)次裝箱拆箱性能明顯不如直接用基本類型long sum。2.3 循環(huán)中刪除集合元素ConcurrentModificationException的真相下面這段代碼跑起來(lái)必拋ConcurrentModificationExceptionListString list new ArrayList(); list.add(A); list.add(B); list.add(C); for (String s : list) { if (B.equals(s)) { list.remove(s); } }很多人沒(méi)搞懂為什么不能在foreach里刪除元素。實(shí)際上foreach語(yǔ)法糖的背后是迭代器Iterator它除了hasNext()和next()之外內(nèi)部還有一個(gè)modCount的校驗(yàn)機(jī)制。集合每次做結(jié)構(gòu)性修改增、刪都會(huì)讓modCount加一。迭代器初始化時(shí)保存了當(dāng)時(shí)的expectedModCount每次調(diào)用next()都會(huì)檢查兩者的值不一致就拋ConcurrentModificationException。這個(gè)設(shè)計(jì)就是為了盡早發(fā)現(xiàn)問(wèn)題結(jié)構(gòu)已經(jīng)變了迭代器卻不知道再往下取元素就可能出現(xiàn)臟數(shù)據(jù)。list.remove(s)直接修改了集合的modCount迭代器里保存的expectedModCount沒(méi)變兩個(gè)數(shù)對(duì)不上下次循環(huán)進(jìn)入next()就炸了。正確的刪除方式有三個(gè)。最傳統(tǒng)的是手動(dòng)使用迭代器IteratorString iterator list.iterator(); while (iterator.hasNext()) { String s iterator.next(); if (B.equals(s)) { iterator.remove(); } }這里iterator.remove()會(huì)在更新集合狀態(tài)的同時(shí)同步修改迭代器內(nèi)部的expectedModCount所以不會(huì)拋異常。Java 8之后更推薦直接用removeIflist.removeIf(s - B.equals(s));removeIf在Collection接口的默認(rèn)方法里實(shí)現(xiàn)內(nèi)部已經(jīng)幫你處理好了迭代器和modCount的同步一行代碼解決問(wèn)題。還有一種寫法是用普通for循環(huán)從后往前遍歷用下標(biāo)刪除for (int i list.size() - 1; i 0; i--) { if (B.equals(list.get(i))) { list.remove(i); } }這種寫法不通過(guò)迭代器所以不會(huì)碰modCount校驗(yàn)但只適用于ArrayList這類有隨機(jī)訪問(wèn)能力的List。它有個(gè)隱患每次remove(i)都會(huì)觸發(fā)一次數(shù)組元素搬移如果刪除的元素很多性能并不好。比起removeIf這種寫法只適合在需要精確控制下標(biāo)的老代碼里用。注意removeIf是基于Lambda表達(dá)式的API如果面試官問(wèn)“為什么用removeIf不會(huì)拋異常”你可以直接指出它內(nèi)部使用了Iterator的一個(gè)不可見(jiàn)實(shí)例并通過(guò)expectedModCount同步機(jī)制保證了一致性。3. 異常與報(bào)錯(cuò)排查看到堆棧別慌先定位類型3.1 NoClassDefFoundError與ClassNotFoundException兩個(gè)“找不到類”的區(qū)別異常堆棧里出現(xiàn)java.lang.NoClassDefFoundError: java/applet/Applet這類信息時(shí)剛開(kāi)始排查的人很容易一頭霧水是不是classpath配錯(cuò)了類文件不在其實(shí)這個(gè)具體報(bào)錯(cuò)里的關(guān)鍵不是“找不到類”這件事本身而是“找不到哪個(gè)類”——java.applet.Applet是JDK 9之前就存在、JDK 9開(kāi)始被逐步廢棄、最終在新版本JDK中移除了一個(gè)組件。如果老項(xiàng)目或者老依賴還在引用它在JDK 9以上的環(huán)境里運(yùn)行就會(huì)報(bào)這個(gè)錯(cuò)誤。但NoClassDefFoundError和ClassNotFoundException是兩種不同的異常弄清兩者的區(qū)別是Java異常知識(shí)里的高頻考點(diǎn)。ClassNotFoundException是一個(gè)Exception受檢異常它出現(xiàn)在程序主動(dòng)通過(guò)反射加載某個(gè)類的時(shí)候比如Class.forName(com.example.MyClass)但classpath里根本沒(méi)有這個(gè)類。這是“運(yùn)行時(shí)才發(fā)現(xiàn)的缺失”代碼編譯時(shí)不報(bào)錯(cuò)因?yàn)槟銈魅氲念惷亲址?。NoClassDefFoundError是一個(gè)Error它出現(xiàn)在類已經(jīng)在編譯期存在但運(yùn)行時(shí)加載時(shí)找不到。最常見(jiàn)的情形是編譯某個(gè)類時(shí)依賴的另一個(gè)類還在后來(lái)把那個(gè)類從classpath里刪了或者打包時(shí)漏打了運(yùn)行時(shí)就能看到這個(gè)Error。還有一種典型場(chǎng)景是靜態(tài)初始化失敗比如類的靜態(tài)代碼塊拋異常類初始化失敗下次再用到這個(gè)類時(shí)也會(huì)拋NoClassDefFoundError?？磫?wèn)題的方法也很直接。第一看異常類型是Exception還是ErrorError意味著問(wèn)題幾乎不可恢復(fù)不是靠try-catch能接住的。第二看后面跟的類名是哪個(gè)去項(xiàng)目里全局搜索這個(gè)類確認(rèn)它是否還在。這里可能有個(gè)反直覺(jué)的點(diǎn)搜代碼里找不到某類不代表classpath里沒(méi)有它有可能藏在某個(gè)依賴jar包里。第三關(guān)注當(dāng)前JDK版本定位到JDK版本變遷引發(fā)的類移除問(wèn)題這種最容易在升級(jí)JDK之后集中爆發(fā)?；氐絡(luò)ava/applet/Applet這個(gè)具體報(bào)錯(cuò)如果你確定項(xiàng)目本身沒(méi)有寫Applet相關(guān)代碼幾乎可以判定是某個(gè)老依賴傳遞引用了Applet類。排查時(shí)可以在命令行里用jdeps分析jar包依賴關(guān)系找出誰(shuí)在引用Appletjdeps --jdkinternals --recursive your-app.jar這個(gè)命令會(huì)列出jar包中所有對(duì)JDK內(nèi)部API的引用包括已移除的模塊好用得很。找到引用方之后要么升級(jí)那個(gè)老依賴的版本要么在代碼層面把Applet相關(guān)調(diào)用去掉。注意有時(shí)候引用隱藏在反射代碼里jdeps也掃不出來(lái)那就只能全局搜Class.forName和Applet關(guān)鍵字了。3.2 Redis的increment()報(bào)錯(cuò)“is not integer or out of range”用Spring Data Redis操作Redis時(shí)經(jīng)常有人碰到這個(gè)異常ERR value is not an integer or out of range觸發(fā)代碼往往是redisTemplate.opsForValue().increment(someKey);第一反應(yīng)是我沒(méi)存過(guò)任何非數(shù)字內(nèi)容到這個(gè)key啊為什么Redis說(shuō)“不是整數(shù)”要理解這個(gè)報(bào)錯(cuò)得先看Redis本身的INCR命令。INCR在Redis里是一個(gè)原子自增命令它要求key當(dāng)前存儲(chǔ)的值能被解釋為一個(gè)十進(jìn)制整數(shù)而且這個(gè)整數(shù)在64位有符號(hào)整數(shù)的范圍內(nèi)。如果key不存在Redis會(huì)先把它初始化為0再自增返回1。但如果key的值是字符串或者其他無(wú)法解析為整數(shù)的格式Redis直接拒絕執(zhí)行并返回上面的錯(cuò)誤。那為什么value看起來(lái)是正常的Redis還是拒絕呢我遇到過(guò)兩類典型場(chǎng)景。第一類是key已經(jīng)被其他業(yè)務(wù)邏輯寫入過(guò)非字符串格式的值。比如你用的同一個(gè)Redis數(shù)據(jù)庫(kù)某個(gè)地方用set存了這個(gè)key的舊值內(nèi)容類似abc或JSON串你的increment()再去執(zhí)行自然失敗。這種問(wèn)題的排查思路很簡(jiǎn)單先到Redis里看這個(gè)key當(dāng)前的數(shù)據(jù)類型和值。redis-cli TYPE someKey GET someKeyTYPE返回string、list、hash這些類型如果類型不是stringINCR用不了。如果類型是string再GET看看具體內(nèi)容基本一眼能看出問(wèn)題。第二類場(chǎng)景更隱蔽和Spring Data Redis的序列化機(jī)制有關(guān)。RedisTemplate默認(rèn)使用JdkSerializationRedisSerializer把key和value都做Java序列化存入Redis時(shí)value前面會(huì)帶一串二進(jìn)制頭而StringRedisTemplate使用StringRedisSerializer存進(jìn)去的就是純字符串。如果你在同一個(gè)項(xiàng)目里混用了兩種Template操作了同一個(gè)key就會(huì)出現(xiàn)“存進(jìn)去的是亂碼讀出來(lái)格式對(duì)不上”的情況increment()拿到的值不是合法整數(shù)直接報(bào)錯(cuò)。這種坑排查起來(lái)相當(dāng)費(fèi)勁因?yàn)槟阒饔^上覺(jué)得這個(gè)key只有你寫的代碼在操作。解決這類問(wèn)題有兩個(gè)思路。一是統(tǒng)一序列化器同一個(gè)key的讀寫不要混用不同的Template。二是對(duì)特定業(yè)務(wù)場(chǎng)景直接指定用ValueOperations之前先檢查類型或做防御性刪除if (Boolean.FALSE.equals(redisTemplate.hasKey(key))) { redisTemplate.opsForValue().set(key, 0); } redisTemplate.opsForValue().increment(key);這里有個(gè)細(xì)節(jié)要注意hasKey判斷的是key不存在而不是“值不是數(shù)字”。如果key存在但值不是數(shù)字這種防御性初始化幫不上忙。真正常規(guī)做法是從業(yè)務(wù)邏輯上保證這個(gè)key只會(huì)被增加數(shù)字在寫入數(shù)據(jù)之前先清洗掉歷史臟數(shù)據(jù)可以用redisTemplate.delete(key)先清理再正常自增。注意Spring Data Redis的increment()方法還支持傳入增量步長(zhǎng)比如increment(key, 5)但如果value本身不是數(shù)字照樣會(huì)拋同樣的錯(cuò)。排查時(shí)優(yōu)先看Redis里的真實(shí)數(shù)據(jù)和數(shù)據(jù)類型不要一頭扎進(jìn)Java代碼里找bug。4. 面試與經(jīng)典算法八股文背后的原理4.1 冒泡排序兩種寫法與優(yōu)化空間冒泡排序是個(gè)經(jīng)典的入門排序算法但別因?yàn)樗?jiǎn)單就輕視。很多面試官喜歡從冒泡排序切入看你代碼風(fēng)格、變量命名、邊界條件處理以及是不是只會(huì)默寫。冒泡排序的核心思想是每一輪迭代比較相鄰元素如果順序不對(duì)就交換最大的元素像氣泡一樣逐步“冒”到數(shù)組末尾。經(jīng)過(guò)n-1輪后整個(gè)數(shù)組有序。最基礎(chǔ)的寫法public static void bubbleSort(int[] arr) { int n arr.length; for (int i 0; i n - 1; i) { for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; } } } }內(nèi)層循環(huán)的n - 1 - i是關(guān)鍵第i輪結(jié)束后數(shù)組末尾的i個(gè)元素已經(jīng)是全局最大的i個(gè)它們已經(jīng)就位不再需要參與后續(xù)比較。這個(gè)邊界條件寫錯(cuò)的人特別多常見(jiàn)錯(cuò)誤是寫成n - 1導(dǎo)致多算了好幾輪無(wú)效比較影響不大但有失精確。優(yōu)化版是在每一輪里記錄是否發(fā)生了交換。如果某一輪從頭走到尾都沒(méi)有任何一次交換說(shuō)明數(shù)組已經(jīng)有序可以提前終止public static void bubbleSortOptimized(int[] arr) { int n arr.length; for (int i 0; i n - 1; i) { boolean swapped false; for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; swapped true; } } if (!swapped) { break; } } }加了swapped標(biāo)記之后最好情況數(shù)組已經(jīng)有序的時(shí)間復(fù)雜度從O(n2)降為O(n)只需要跑一輪就能退出。平均和最壞情況還是O(n2)因?yàn)榭傮w上它仍然需要反復(fù)比較相鄰元素?？臻g復(fù)雜度O(1)是原地排序。面試時(shí)如果讓你用冒泡排序記得說(shuō)清楚它的優(yōu)缺點(diǎn)。優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單、穩(wěn)定相同元素相對(duì)位置不變、原地排序。缺點(diǎn)是慢數(shù)據(jù)量大時(shí)明顯頂不住。實(shí)際開(kāi)發(fā)中沒(méi)人會(huì)用冒泡排大數(shù)組面試官考察它更多是想確認(rèn)你對(duì)基礎(chǔ)算法的理解深度。比如你提到優(yōu)化版冒泡利用了“是否有交換”的標(biāo)記這就能和“最好情況O(n)”的復(fù)雜度分析串起來(lái)比單純默寫代碼強(qiáng)很多。其實(shí)冒泡排序和Java標(biāo)準(zhǔn)庫(kù)的Arrays.sort()差距有多大呢Arrays.sort()對(duì)基本類型數(shù)組用雙軸快排對(duì)對(duì)象數(shù)組用TimSort大數(shù)據(jù)量下性能完全不在一個(gè)量級(jí)。手寫排序在業(yè)務(wù)代碼里基本沒(méi)有存在意義要排序直接調(diào)庫(kù)就行。算法的價(jià)值在于理解思維方法這在面試之外才是最重要的收獲。4.2 動(dòng)態(tài)代理JDK動(dòng)態(tài)代理與CGLIB的區(qū)別動(dòng)態(tài)代理是Spring AOP的底層基礎(chǔ)面試頻率極高。問(wèn)法通常是“說(shuō)說(shuō)JDK動(dòng)態(tài)代理和CGLIB的區(qū)別”或者“Spring AOP默認(rèn)用哪種代理方式”。先明確概念。代理模式的目標(biāo)是給某個(gè)對(duì)象提供一個(gè)代理對(duì)象由代理對(duì)象控制對(duì)原對(duì)象的訪問(wèn)。調(diào)用方不直接操作目標(biāo)對(duì)象而是通過(guò)代理代理可以在調(diào)用前后插入額外邏輯。靜態(tài)代理在編譯期就確定代理關(guān)系一個(gè)接口要寫一個(gè)代理類。動(dòng)態(tài)代理則是在運(yùn)行期動(dòng)態(tài)生成代理類。JDK動(dòng)態(tài)代理要求目標(biāo)對(duì)象必須實(shí)現(xiàn)至少一個(gè)接口。它通過(guò)java.lang.reflect.Proxy類在運(yùn)行時(shí)為接口生成代理類調(diào)用Proxy.newProxyInstance()傳入類加載器、接口數(shù)組和一個(gè)InvocationHandler。代理對(duì)象的方法調(diào)用會(huì)被轉(zhuǎn)發(fā)到InvocationHandler.invoke()方法所以可以在invoke里做增強(qiáng)邏輯。下面的代碼是一個(gè)簡(jiǎn)化示例public interface UserService { void addUser(String name); } public class UserServiceImpl implements UserService { Override public void addUser(String name) { System.out.println(添加用戶: name); } } UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (proxyObj, method, args) - { System.out.println(方法調(diào)用前記錄日志); Object result method.invoke(target, args); System.out.println(方法調(diào)用后收尾); return result; }); proxy.addUser(張三);CGLIBCode Generation Library的做法不同它通過(guò)生成目標(biāo)類的一個(gè)子類來(lái)創(chuàng)建代理對(duì)象不需要接口。因?yàn)槟繕?biāo)類被繼承被final修飾的類和方法都無(wú)法被CGLIB代理。CGLIB底層依賴ASM字節(jié)碼操作庫(kù)在運(yùn)行期直接生成新的字節(jié)碼類。Spring Boot默認(rèn)的代理策略是目標(biāo)類有接口就用JDK動(dòng)態(tài)代理沒(méi)有接口就用CGLIB。從Spring Boot 2.x開(kāi)始即使對(duì)象有接口默認(rèn)也更傾向于用CGLIB來(lái)避免某些邊界問(wèn)題不過(guò)這屬于框架細(xì)節(jié)不同版本行為有差異。兩者的核心對(duì)比如下對(duì)比項(xiàng)JDK動(dòng)態(tài)代理CGLIB代理目標(biāo)條件必須實(shí)現(xiàn)接口不要求接口不能代理final類原理運(yùn)行期生成接口的代理實(shí)現(xiàn)類運(yùn)行期生成目標(biāo)類的子類依賴JDK內(nèi)置無(wú)需額外依賴需要asm等字節(jié)碼庫(kù)被final修飾的方法可以正常工作無(wú)法被代理性能較高生成代理類輕量稍重創(chuàng)建代理時(shí)需生成子類字節(jié)碼實(shí)際工作中最常見(jiàn)的動(dòng)態(tài)代理應(yīng)用場(chǎng)景就是Spring AOP。比如你給一個(gè)Service方法加TransactionalSpring容器里的bean不再是原來(lái)的UserServiceImpl對(duì)象而是它的代理對(duì)象。調(diào)用方拿到的引用指向代理代理在執(zhí)行業(yè)務(wù)方法前開(kāi)啟事務(wù)方法拋異常時(shí)回滾正常結(jié)束時(shí)提交。理解了這套機(jī)制后面排查事務(wù)失效問(wèn)題就多了一把鑰匙如果某個(gè)類里的私有方法加了Transactional或者一個(gè)方法內(nèi)部直接this調(diào)用同類的另一個(gè)方法這些都不會(huì)經(jīng)過(guò)代理對(duì)象事務(wù)注解自然無(wú)效。最后提一個(gè)面試愛(ài)問(wèn)的延伸點(diǎn)為什么Spring的注解驅(qū)動(dòng)事務(wù)只對(duì)public方法生效因?yàn)镴DK動(dòng)態(tài)代理和CGLIB代理只能在方法被外部調(diào)用時(shí)攔截而this內(nèi)部調(diào)用不會(huì)經(jīng)過(guò)代理同時(shí)CGLIB生成子類時(shí)private方法不會(huì)被子類覆蓋final方法也不行。所以Spring要求事務(wù)方法必須是public且從外部調(diào)用才能被增強(qiáng)。我個(gè)人覺(jué)得動(dòng)態(tài)代理這部分不用背源碼核心就是把代理“在調(diào)用鏈上插入邏輯”這個(gè)思想想明白。代理對(duì)象和被代理對(duì)象的關(guān)系就像中介和房東租客以為自己在跟房東打交道其實(shí)合同走的是中介。中間那層中介能幫你做驗(yàn)證、記賬、協(xié)調(diào)還能隨時(shí)決定這單生意要不要做。理解了這個(gè)場(chǎng)景后面看各種框架的攔截器、過(guò)濾器時(shí)都會(huì)順暢很多。 Java面試避坑指南：環(huán)境配置、核心API、異常排查與算法原理
這一篇是Java基礎(chǔ)常見(jiàn)問(wèn)題系列的第三篇。前面兩篇聊了不少語(yǔ)法細(xì)節(jié)和集合框架的坑結(jié)果后臺(tái)收到最多的留言反而是“環(huán)境配置翻車”“報(bào)錯(cuò)看不懂”“面試被問(wèn)住”這幾類。所以這篇我換個(gè)思路不再按語(yǔ)法書(shū)目錄走而是把熱搜詞里大家真正高頻搜索的問(wèn)題挑出來(lái)分成環(huán)境與編譯期、核心API、異常排查、面試與算法四個(gè)板塊逐個(gè)拆開(kāi)揉碎講清楚。不管你是剛裝好JDK準(zhǔn)備寫第一個(gè)Hello World還是工作兩三年后回頭補(bǔ)基礎(chǔ)這篇都適合花二十分鐘認(rèn)真過(guò)一遍。所有問(wèn)題都是實(shí)際開(kāi)發(fā)里真會(huì)遇到的每一條背后都有可復(fù)現(xiàn)的報(bào)錯(cuò)信息或者可驗(yàn)證的代碼看完能直接用不是那種背完就忘的八股問(wèn)答。1. 環(huán)境與編譯期問(wèn)題裝對(duì)JDK只是開(kāi)始1.1 JAVA_HOME與PATH為什么配了環(huán)境變量還是報(bào)錯(cuò)很多新手第一次裝JDK網(wǎng)上搜了一篇教程照著配完環(huán)境變量打開(kāi)命令行敲java -version有輸出以為就萬(wàn)事大吉了。結(jié)果沒(méi)過(guò)多久用IDEA建項(xiàng)目時(shí)提示找不到JDK或者寫了一個(gè)啟動(dòng)腳本雙擊運(yùn)行直接報(bào)錯(cuò)這時(shí)候才發(fā)現(xiàn)環(huán)境變量沒(méi)那么簡(jiǎn)單。先搞清楚JAVA_HOME和PATH各自是干什么的。JAVA_HOME是一個(gè)自定義變量它指向JDK的安裝根目錄比如C:\Program Files\Java\jdk-17。JDK本身以及Tomcat、Maven、Gradle這些工具啟動(dòng)時(shí)都要靠這個(gè)變量找到JDK的位置。而PATH是系統(tǒng)用來(lái)找可執(zhí)行文件的路徑集合你在命令行里敲java系統(tǒng)會(huì)按順序遍歷PATH列出的每個(gè)目錄找到名為java.exe的文件就執(zhí)行。所以PATH里必須包含%JAVA_HOME%\bin否則系統(tǒng)找不到j(luò)ava命令。配完了還報(bào)錯(cuò)最常見(jiàn)的原因有三個(gè)。第一個(gè)是PATH的系統(tǒng)變量和用戶變量沖突。Windows系統(tǒng)的環(huán)境變量分“用戶變量”和“系統(tǒng)變量”兩欄兩者最終會(huì)合并生效但順序上有講究用戶變量在前系統(tǒng)變量在后。如果你在用戶變量里配了一個(gè)舊版本JDK的路徑又在系統(tǒng)變量里配了新版JDK最后生效的可能是用戶變量里那個(gè)舊的。解決辦法很簡(jiǎn)單打開(kāi)命令行執(zhí)行where java它會(huì)列出所有找到的java.exe及其路徑一眼就能看出實(shí)際用的是哪個(gè)。第二個(gè)是變量順序問(wèn)題。有人把JAVA_HOME刪了直接在PATH里寫死絕對(duì)路徑C:\Program Files\Java\jdk-17\bin這樣單獨(dú)看沒(méi)問(wèn)題。但你日后升級(jí)JDK版本比如從17升到21就得再改一遍PATH而且如果你裝了多個(gè)JDK或者有其他軟件往PATH里塞了Java路徑就很容易亂。標(biāo)準(zhǔn)做法還是先設(shè)置JAVA_HOME然后PATH里寫%JAVA_HOME%\bin這樣以后切版本只改JAVA_HOME一處。第三個(gè)是配置了但沒(méi)生效。環(huán)境變量修改后已經(jīng)打開(kāi)的命令行窗口不會(huì)自動(dòng)刷新需要重開(kāi)一個(gè)新的命令行窗口。IDEA如果是在修改之前啟動(dòng)的也要重啟IDEA。這個(gè)原因最蠢也最容易踩。再補(bǔ)充一個(gè)高頻場(chǎng)景本機(jī)裝了多個(gè)JDK比如一個(gè)8用在老項(xiàng)目一個(gè)17用在新項(xiàng)目。這時(shí)候只靠改JAVA_HOME來(lái)實(shí)現(xiàn)切換并不總是有效因?yàn)镻ATH里如果存在JDK8自帶的jre路徑或者之前裝過(guò)Oracle官網(wǎng)版的Java注冊(cè)表里也留了版本信息某些軟件會(huì)去讀注冊(cè)表而不是讀JAVA_HOME。我的建議是日常開(kāi)發(fā)統(tǒng)一用JAVA_HOME切換必要時(shí)配合where java驗(yàn)證如果真的需要頻繁切換并希望更省心可以借助開(kāi)源的sdkman或者Windows下的SDKMAN-like工具來(lái)管理多版本JDK不過(guò)基礎(chǔ)思路還是理解環(huán)境變量的優(yōu)先級(jí)。1.2 Lombok與編譯器版本沖突一句話背后的連鎖反應(yīng)這兩年JDK的發(fā)布節(jié)奏變成半年一個(gè)大版本很多團(tuán)隊(duì)還停在JDK8但總有喜歡追新的人把開(kāi)發(fā)環(huán)境的JDK升到了17、21甚至更新。升完JDK之后一個(gè)高頻報(bào)錯(cuò)就出現(xiàn)了java: you arent using a compiler supported by lombok, so lombok will not work.這句話從字面看是“你用的編譯器Lombok不支持”但很多人不理解為什么javac換了個(gè)版本Lombok就罷工了。這里要交代一下Lombok的工作原理。Lombok不是普通的jar包它在編譯階段通過(guò)Java的注解處理器Annotation Processor機(jī)制介入編譯過(guò)程在抽象語(yǔ)法樹(shù)AST上做修改往類里注入getter、setter、builder等方法。JDK的編譯器javac內(nèi)部實(shí)現(xiàn)對(duì)Lombok來(lái)說(shuō)就是一套特定的APIJDK版本一變這張API就可能有變動(dòng)Lombok沒(méi)跟上就必須拒絕工作否則硬往AST里塞代碼指不定編譯出什么畸形字節(jié)碼。所以這個(gè)問(wèn)題的本質(zhì)是Lombok版本太老不支持當(dāng)前JDK版本。解決辦法也直接——升級(jí)Lombok。以Maven項(xiàng)目為例引入的依賴坐標(biāo)保持不變但版本號(hào)需要跟著JDK版本走dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId version1.18.36/version scopeprovided/scope /dependency以我的經(jīng)驗(yàn)JDK17用Lombok 1.18.20以上基本沒(méi)問(wèn)題JDK21建議直接用1.18.30以上再保守一點(diǎn)就選最新的release版本。Gradle項(xiàng)目的話在dependencies里同步調(diào)整版本即可。排查這個(gè)報(bào)錯(cuò)時(shí)還有幾個(gè)容易忽略的細(xì)節(jié)。我遇到過(guò)升級(jí)了Lombok版本、重啟了IDEA仍然報(bào)同樣錯(cuò)誤的情況后來(lái)發(fā)現(xiàn)是IDEA的Build選項(xiàng)里勾選了Delegate IDE build/run actions to Maven本質(zhì)上是Maven的編譯進(jìn)程還在用舊的注解處理器。這時(shí)候要執(zhí)行一次mvn clean compile看Maven是不是能正常編譯。如果Maven能過(guò)而IDEA不能過(guò)檢查IDEA的Settings → Build → Compiler → Annotation Processors是否勾選了Enable annotation processing。Lombok要在IDE里生效這一步必須打開(kāi)。注意有些項(xiàng)目會(huì)同時(shí)在pom.xml里顯式引入lombok-maven-plugin這個(gè)老插件只在少數(shù)場(chǎng)景有用絕大多數(shù)情況下不需要升級(jí)到新版IDE和Lombok版本就能解決。2. 核心API與常用類平時(shí)寫代碼最容易栽的地方2.1 String、StringBuilder、StringBuffer不只是“拼接效率”那點(diǎn)事Java面試?yán)颯tring相關(guān)的題永遠(yuǎn)不過(guò)時(shí)但很多人背了“String不可變、StringBuffer線程安全、StringBuilder線程不安全”就以為掌握全場(chǎng)了一上手寫代碼照樣掉坑。先說(shuō)一個(gè)最典型的錯(cuò)誤在循環(huán)里用拼接字符串。String result ; for (int i 0; i 10000; i) { result i ,; }這段代碼在語(yǔ)法上沒(méi)有任何問(wèn)題但性能很差。原因是String類是不可變的每次都會(huì)創(chuàng)建新的字符串對(duì)象舊的字符串對(duì)象變成垃圾等待回收。循環(huán)一萬(wàn)次就會(huì)創(chuàng)建一萬(wàn)個(gè)中間字符串對(duì)象。你可能說(shuō)編譯器不是會(huì)優(yōu)化成StringBuilder嗎確實(shí)javac會(huì)將單個(gè)表達(dá)式優(yōu)化成new StringBuilder().append()...toString()但這是在單條語(yǔ)句內(nèi)部跨循環(huán)迭代時(shí)每一次都會(huì)創(chuàng)建獨(dú)立的StringBuilder照樣有性能損耗。正確寫法是用StringBuilderStringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i).append(,); } String result sb.toString();這里.append(i).append(,)連續(xù)調(diào)用是StringBuilder的鏈?zhǔn)秸{(diào)用設(shè)計(jì)每步返回同一個(gè)對(duì)象從頭到尾只創(chuàng)建一個(gè)StringBuilder實(shí)例。至于StringBuffer它的所有公開(kāi)方法幾乎都加了synchronized所以在單線程環(huán)境下的性能比StringBuilder差多線程環(huán)境下兩個(gè)類也都不適合作為共享可變狀態(tài)來(lái)使用。換句話說(shuō)StringBuffer的“線程安全”在絕大多數(shù)場(chǎng)景是個(gè)偽需求。我在實(shí)際項(xiàng)目中基本只在一種情況用StringBuffer面試Demo里為了展示線程安全。日常開(kāi)發(fā)統(tǒng)一用StringBuilder就好。還有一個(gè)衍生問(wèn)題值得講為什么String設(shè)計(jì)成不可變網(wǎng)上答案很多我挑幾個(gè)關(guān)鍵的。第一字符串常量池需要靠不可變性來(lái)保證安全性同一個(gè)字符串字面量被多個(gè)變量引用如果其中一處修改了內(nèi)容其他引用就全亂了。第二作為HashMap的key不可變保證了hashCode的穩(wěn)定性如果key的hashCode變化HashMap就再也找不到這個(gè)鍵了。第三String對(duì)象會(huì)被網(wǎng)絡(luò)傳輸、文件讀寫大量使用不可變讓這些場(chǎng)景更安全避免意外修改。面試時(shí)如果被問(wèn)到“String可以繼承嗎”答案是不可以String是final的。這個(gè)設(shè)計(jì)不是為了防程序員而是為了確保字符串的不可變性和安全性不被破壞還有編譯器的各種優(yōu)化可以放心假設(shè)String對(duì)象的值不會(huì)變。2.2 包裝類緩存與equals比較100和1000的區(qū)別來(lái)看一段代碼Integer a 100; Integer b 100; System.out.println(a b); // true Integer c 1000; Integer d 1000; System.out.println(c d); // false同樣是用比較兩個(gè)Integer為什么一個(gè)輸出true一個(gè)輸出false原因是Java在Integer類內(nèi)部維護(hù)了一個(gè)緩存數(shù)組默認(rèn)緩存了-128到127之間的所有Integer對(duì)象。當(dāng)你通過(guò)自動(dòng)裝箱創(chuàng)建Integer對(duì)象時(shí)如果值在緩存范圍內(nèi)直接返回緩存中已有的同一個(gè)對(duì)象所以100 100是true。值超過(guò)127緩存中不存在就得新建對(duì)象所以1000 1000用了兩個(gè)不同對(duì)象比較的是引用地址自然是false。這個(gè)緩存機(jī)制在Java面試?yán)飵缀醣乜?。JDK的源碼里有個(gè)IntegerCache內(nèi)部類其中l(wèi)ow默認(rèn)-128high默認(rèn)127high可以通過(guò)啟動(dòng)參數(shù)-XX:AutoBoxCacheMax1000調(diào)大。除了Integer其他整數(shù)包裝類也有類似機(jī)制Byte、Short、Long緩存范圍固定為-128到127Character緩存0到127。浮點(diǎn)型Float、Double沒(méi)有緩存因?yàn)檎麛?shù)范圍內(nèi)的緩存數(shù)量有限而浮點(diǎn)數(shù)理論上無(wú)限?；谶@個(gè)原理開(kāi)發(fā)中用包裝對(duì)象做比較時(shí)必須記住一個(gè)規(guī)矩只要是比較兩個(gè)包裝類對(duì)象的值一律用equals()或者轉(zhuǎn)成基本類型再用。比如判斷兩個(gè)Integer是否相等寫成a.equals(b)或者a.intValue() b.intValue()。Java 7之后還可以用Objects.equals(a, b)內(nèi)部會(huì)做空指針判斷比a.equals(b)更嚴(yán)謹(jǐn)因?yàn)楹笳咴赼為null時(shí)直接空指針。再延伸一個(gè)相關(guān)知識(shí)點(diǎn)自動(dòng)裝箱Autoboxing和自動(dòng)拆箱Unboxing。Integer a 100本質(zhì)是Integer a Integer.valueOf(100)int x a本質(zhì)是x a.intValue()。在循環(huán)或者高頻運(yùn)算里如果反復(fù)在Integer和int之間轉(zhuǎn)換會(huì)額外產(chǎn)生對(duì)象創(chuàng)建的開(kāi)銷。比如寫Long sum 0L; for (long i 0; i 100000; i) { sum i; }由于sum是Long包裝類型每次sum i都要先拆箱成long做加法再裝箱回Long循環(huán)十萬(wàn)次就產(chǎn)生十萬(wàn)次裝箱拆箱性能明顯不如直接用基本類型long sum。2.3 循環(huán)中刪除集合元素ConcurrentModificationException的真相下面這段代碼跑起來(lái)必拋ConcurrentModificationExceptionListString list new ArrayList(); list.add(A); list.add(B); list.add(C); for (String s : list) { if (B.equals(s)) { list.remove(s); } }很多人沒(méi)搞懂為什么不能在foreach里刪除元素。實(shí)際上foreach語(yǔ)法糖的背后是迭代器Iterator它除了hasNext()和next()之外內(nèi)部還有一個(gè)modCount的校驗(yàn)機(jī)制。集合每次做結(jié)構(gòu)性修改增、刪都會(huì)讓modCount加一。迭代器初始化時(shí)保存了當(dāng)時(shí)的expectedModCount每次調(diào)用next()都會(huì)檢查兩者的值不一致就拋ConcurrentModificationException。這個(gè)設(shè)計(jì)就是為了盡早發(fā)現(xiàn)問(wèn)題結(jié)構(gòu)已經(jīng)變了迭代器卻不知道再往下取元素就可能出現(xiàn)臟數(shù)據(jù)。list.remove(s)直接修改了集合的modCount迭代器里保存的expectedModCount沒(méi)變兩個(gè)數(shù)對(duì)不上下次循環(huán)進(jìn)入next()就炸了。正確的刪除方式有三個(gè)。最傳統(tǒng)的是手動(dòng)使用迭代器IteratorString iterator list.iterator(); while (iterator.hasNext()) { String s iterator.next(); if (B.equals(s)) { iterator.remove(); } }這里iterator.remove()會(huì)在更新集合狀態(tài)的同時(shí)同步修改迭代器內(nèi)部的expectedModCount所以不會(huì)拋異常。Java 8之后更推薦直接用removeIflist.removeIf(s - B.equals(s));removeIf在Collection接口的默認(rèn)方法里實(shí)現(xiàn)內(nèi)部已經(jīng)幫你處理好了迭代器和modCount的同步一行代碼解決問(wèn)題。還有一種寫法是用普通for循環(huán)從后往前遍歷用下標(biāo)刪除for (int i list.size() - 1; i 0; i--) { if (B.equals(list.get(i))) { list.remove(i); } }這種寫法不通過(guò)迭代器所以不會(huì)碰modCount校驗(yàn)但只適用于ArrayList這類有隨機(jī)訪問(wèn)能力的List。它有個(gè)隱患每次remove(i)都會(huì)觸發(fā)一次數(shù)組元素搬移如果刪除的元素很多性能并不好。比起removeIf這種寫法只適合在需要精確控制下標(biāo)的老代碼里用。注意removeIf是基于Lambda表達(dá)式的API如果面試官問(wèn)“為什么用removeIf不會(huì)拋異常”你可以直接指出它內(nèi)部使用了Iterator的一個(gè)不可見(jiàn)實(shí)例并通過(guò)expectedModCount同步機(jī)制保證了一致性。3. 異常與報(bào)錯(cuò)排查看到堆棧別慌先定位類型3.1 NoClassDefFoundError與ClassNotFoundException兩個(gè)“找不到類”的區(qū)別異常堆棧里出現(xiàn)java.lang.NoClassDefFoundError: java/applet/Applet這類信息時(shí)剛開(kāi)始排查的人很容易一頭霧水是不是classpath配錯(cuò)了類文件不在其實(shí)這個(gè)具體報(bào)錯(cuò)里的關(guān)鍵不是“找不到類”這件事本身而是“找不到哪個(gè)類”——java.applet.Applet是JDK 9之前就存在、JDK 9開(kāi)始被逐步廢棄、最終在新版本JDK中移除了一個(gè)組件。如果老項(xiàng)目或者老依賴還在引用它在JDK 9以上的環(huán)境里運(yùn)行就會(huì)報(bào)這個(gè)錯(cuò)誤。但NoClassDefFoundError和ClassNotFoundException是兩種不同的異常弄清兩者的區(qū)別是Java異常知識(shí)里的高頻考點(diǎn)。ClassNotFoundException是一個(gè)Exception受檢異常它出現(xiàn)在程序主動(dòng)通過(guò)反射加載某個(gè)類的時(shí)候比如Class.forName(com.example.MyClass)但classpath里根本沒(méi)有這個(gè)類。這是“運(yùn)行時(shí)才發(fā)現(xiàn)的缺失”代碼編譯時(shí)不報(bào)錯(cuò)因?yàn)槟銈魅氲念惷亲址?。NoClassDefFoundError是一個(gè)Error它出現(xiàn)在類已經(jīng)在編譯期存在但運(yùn)行時(shí)加載時(shí)找不到。最常見(jiàn)的情形是編譯某個(gè)類時(shí)依賴的另一個(gè)類還在后來(lái)把那個(gè)類從classpath里刪了或者打包時(shí)漏打了運(yùn)行時(shí)就能看到這個(gè)Error。還有一種典型場(chǎng)景是靜態(tài)初始化失敗比如類的靜態(tài)代碼塊拋異常類初始化失敗下次再用到這個(gè)類時(shí)也會(huì)拋NoClassDefFoundError?？磫?wèn)題的方法也很直接。第一看異常類型是Exception還是ErrorError意味著問(wèn)題幾乎不可恢復(fù)不是靠try-catch能接住的。第二看后面跟的類名是哪個(gè)去項(xiàng)目里全局搜索這個(gè)類確認(rèn)它是否還在。這里可能有個(gè)反直覺(jué)的點(diǎn)搜代碼里找不到某類不代表classpath里沒(méi)有它有可能藏在某個(gè)依賴jar包里。第三關(guān)注當(dāng)前JDK版本定位到JDK版本變遷引發(fā)的類移除問(wèn)題這種最容易在升級(jí)JDK之后集中爆發(fā)?；氐絡(luò)ava/applet/Applet這個(gè)具體報(bào)錯(cuò)如果你確定項(xiàng)目本身沒(méi)有寫Applet相關(guān)代碼幾乎可以判定是某個(gè)老依賴傳遞引用了Applet類。排查時(shí)可以在命令行里用jdeps分析jar包依賴關(guān)系找出誰(shuí)在引用Appletjdeps --jdkinternals --recursive your-app.jar這個(gè)命令會(huì)列出jar包中所有對(duì)JDK內(nèi)部API的引用包括已移除的模塊好用得很。找到引用方之后要么升級(jí)那個(gè)老依賴的版本要么在代碼層面把Applet相關(guān)調(diào)用去掉。注意有時(shí)候引用隱藏在反射代碼里jdeps也掃不出來(lái)那就只能全局搜Class.forName和Applet關(guān)鍵字了。3.2 Redis的increment()報(bào)錯(cuò)“is not integer or out of range”用Spring Data Redis操作Redis時(shí)經(jīng)常有人碰到這個(gè)異常ERR value is not an integer or out of range觸發(fā)代碼往往是redisTemplate.opsForValue().increment(someKey);第一反應(yīng)是我沒(méi)存過(guò)任何非數(shù)字內(nèi)容到這個(gè)key啊為什么Redis說(shuō)“不是整數(shù)”要理解這個(gè)報(bào)錯(cuò)得先看Redis本身的INCR命令。INCR在Redis里是一個(gè)原子自增命令它要求key當(dāng)前存儲(chǔ)的值能被解釋為一個(gè)十進(jìn)制整數(shù)而且這個(gè)整數(shù)在64位有符號(hào)整數(shù)的范圍內(nèi)。如果key不存在Redis會(huì)先把它初始化為0再自增返回1。但如果key的值是字符串或者其他無(wú)法解析為整數(shù)的格式Redis直接拒絕執(zhí)行并返回上面的錯(cuò)誤。那為什么value看起來(lái)是正常的Redis還是拒絕呢我遇到過(guò)兩類典型場(chǎng)景。第一類是key已經(jīng)被其他業(yè)務(wù)邏輯寫入過(guò)非字符串格式的值。比如你用的同一個(gè)Redis數(shù)據(jù)庫(kù)某個(gè)地方用set存了這個(gè)key的舊值內(nèi)容類似abc或JSON串你的increment()再去執(zhí)行自然失敗。這種問(wèn)題的排查思路很簡(jiǎn)單先到Redis里看這個(gè)key當(dāng)前的數(shù)據(jù)類型和值。redis-cli TYPE someKey GET someKeyTYPE返回string、list、hash這些類型如果類型不是stringINCR用不了。如果類型是string再GET看看具體內(nèi)容基本一眼能看出問(wèn)題。第二類場(chǎng)景更隱蔽和Spring Data Redis的序列化機(jī)制有關(guān)。RedisTemplate默認(rèn)使用JdkSerializationRedisSerializer把key和value都做Java序列化存入Redis時(shí)value前面會(huì)帶一串二進(jìn)制頭而StringRedisTemplate使用StringRedisSerializer存進(jìn)去的就是純字符串。如果你在同一個(gè)項(xiàng)目里混用了兩種Template操作了同一個(gè)key就會(huì)出現(xiàn)“存進(jìn)去的是亂碼讀出來(lái)格式對(duì)不上”的情況increment()拿到的值不是合法整數(shù)直接報(bào)錯(cuò)。這種坑排查起來(lái)相當(dāng)費(fèi)勁因?yàn)槟阒饔^上覺(jué)得這個(gè)key只有你寫的代碼在操作。解決這類問(wèn)題有兩個(gè)思路。一是統(tǒng)一序列化器同一個(gè)key的讀寫不要混用不同的Template。二是對(duì)特定業(yè)務(wù)場(chǎng)景直接指定用ValueOperations之前先檢查類型或做防御性刪除if (Boolean.FALSE.equals(redisTemplate.hasKey(key))) { redisTemplate.opsForValue().set(key, 0); } redisTemplate.opsForValue().increment(key);這里有個(gè)細(xì)節(jié)要注意hasKey判斷的是key不存在而不是“值不是數(shù)字”。如果key存在但值不是數(shù)字這種防御性初始化幫不上忙。真正常規(guī)做法是從業(yè)務(wù)邏輯上保證這個(gè)key只會(huì)被增加數(shù)字在寫入數(shù)據(jù)之前先清洗掉歷史臟數(shù)據(jù)可以用redisTemplate.delete(key)先清理再正常自增。注意Spring Data Redis的increment()方法還支持傳入增量步長(zhǎng)比如increment(key, 5)但如果value本身不是數(shù)字照樣會(huì)拋同樣的錯(cuò)。排查時(shí)優(yōu)先看Redis里的真實(shí)數(shù)據(jù)和數(shù)據(jù)類型不要一頭扎進(jìn)Java代碼里找bug。4. 面試與經(jīng)典算法八股文背后的原理4.1 冒泡排序兩種寫法與優(yōu)化空間冒泡排序是個(gè)經(jīng)典的入門排序算法但別因?yàn)樗?jiǎn)單就輕視。很多面試官喜歡從冒泡排序切入看你代碼風(fēng)格、變量命名、邊界條件處理以及是不是只會(huì)默寫。冒泡排序的核心思想是每一輪迭代比較相鄰元素如果順序不對(duì)就交換最大的元素像氣泡一樣逐步“冒”到數(shù)組末尾。經(jīng)過(guò)n-1輪后整個(gè)數(shù)組有序。最基礎(chǔ)的寫法public static void bubbleSort(int[] arr) { int n arr.length; for (int i 0; i n - 1; i) { for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; } } } }內(nèi)層循環(huán)的n - 1 - i是關(guān)鍵第i輪結(jié)束后數(shù)組末尾的i個(gè)元素已經(jīng)是全局最大的i個(gè)它們已經(jīng)就位不再需要參與后續(xù)比較。這個(gè)邊界條件寫錯(cuò)的人特別多常見(jiàn)錯(cuò)誤是寫成n - 1導(dǎo)致多算了好幾輪無(wú)效比較影響不大但有失精確。優(yōu)化版是在每一輪里記錄是否發(fā)生了交換。如果某一輪從頭走到尾都沒(méi)有任何一次交換說(shuō)明數(shù)組已經(jīng)有序可以提前終止public static void bubbleSortOptimized(int[] arr) { int n arr.length; for (int i 0; i n - 1; i) { boolean swapped false; for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; swapped true; } } if (!swapped) { break; } } }加了swapped標(biāo)記之后最好情況數(shù)組已經(jīng)有序的時(shí)間復(fù)雜度從O(n2)降為O(n)只需要跑一輪就能退出。平均和最壞情況還是O(n2)因?yàn)榭傮w上它仍然需要反復(fù)比較相鄰元素?？臻g復(fù)雜度O(1)是原地排序。面試時(shí)如果讓你用冒泡排序記得說(shuō)清楚它的優(yōu)缺點(diǎn)。優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單、穩(wěn)定相同元素相對(duì)位置不變、原地排序。缺點(diǎn)是慢數(shù)據(jù)量大時(shí)明顯頂不住。實(shí)際開(kāi)發(fā)中沒(méi)人會(huì)用冒泡排大數(shù)組面試官考察它更多是想確認(rèn)你對(duì)基礎(chǔ)算法的理解深度。比如你提到優(yōu)化版冒泡利用了“是否有交換”的標(biāo)記這就能和“最好情況O(n)”的復(fù)雜度分析串起來(lái)比單純默寫代碼強(qiáng)很多。其實(shí)冒泡排序和Java標(biāo)準(zhǔn)庫(kù)的Arrays.sort()差距有多大呢Arrays.sort()對(duì)基本類型數(shù)組用雙軸快排對(duì)對(duì)象數(shù)組用TimSort大數(shù)據(jù)量下性能完全不在一個(gè)量級(jí)。手寫排序在業(yè)務(wù)代碼里基本沒(méi)有存在意義要排序直接調(diào)庫(kù)就行。算法的價(jià)值在于理解思維方法這在面試之外才是最重要的收獲。4.2 動(dòng)態(tài)代理JDK動(dòng)態(tài)代理與CGLIB的區(qū)別動(dòng)態(tài)代理是Spring AOP的底層基礎(chǔ)面試頻率極高。問(wèn)法通常是“說(shuō)說(shuō)JDK動(dòng)態(tài)代理和CGLIB的區(qū)別”或者“Spring AOP默認(rèn)用哪種代理方式”。先明確概念。代理模式的目標(biāo)是給某個(gè)對(duì)象提供一個(gè)代理對(duì)象由代理對(duì)象控制對(duì)原對(duì)象的訪問(wèn)。調(diào)用方不直接操作目標(biāo)對(duì)象而是通過(guò)代理代理可以在調(diào)用前后插入額外邏輯。靜態(tài)代理在編譯期就確定代理關(guān)系一個(gè)接口要寫一個(gè)代理類。動(dòng)態(tài)代理則是在運(yùn)行期動(dòng)態(tài)生成代理類。JDK動(dòng)態(tài)代理要求目標(biāo)對(duì)象必須實(shí)現(xiàn)至少一個(gè)接口。它通過(guò)java.lang.reflect.Proxy類在運(yùn)行時(shí)為接口生成代理類調(diào)用Proxy.newProxyInstance()傳入類加載器、接口數(shù)組和一個(gè)InvocationHandler。代理對(duì)象的方法調(diào)用會(huì)被轉(zhuǎn)發(fā)到InvocationHandler.invoke()方法所以可以在invoke里做增強(qiáng)邏輯。下面的代碼是一個(gè)簡(jiǎn)化示例public interface UserService { void addUser(String name); } public class UserServiceImpl implements UserService { Override public void addUser(String name) { System.out.println(添加用戶: name); } } UserService target new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), (proxyObj, method, args) - { System.out.println(方法調(diào)用前記錄日志); Object result method.invoke(target, args); System.out.println(方法調(diào)用后收尾); return result; }); proxy.addUser(張三);CGLIBCode Generation Library的做法不同它通過(guò)生成目標(biāo)類的一個(gè)子類來(lái)創(chuàng)建代理對(duì)象不需要接口。因?yàn)槟繕?biāo)類被繼承被final修飾的類和方法都無(wú)法被CGLIB代理。CGLIB底層依賴ASM字節(jié)碼操作庫(kù)在運(yùn)行期直接生成新的字節(jié)碼類。Spring Boot默認(rèn)的代理策略是目標(biāo)類有接口就用JDK動(dòng)態(tài)代理沒(méi)有接口就用CGLIB。從Spring Boot 2.x開(kāi)始即使對(duì)象有接口默認(rèn)也更傾向于用CGLIB來(lái)避免某些邊界問(wèn)題不過(guò)這屬于框架細(xì)節(jié)不同版本行為有差異。兩者的核心對(duì)比如下對(duì)比項(xiàng)JDK動(dòng)態(tài)代理CGLIB代理目標(biāo)條件必須實(shí)現(xiàn)接口不要求接口不能代理final類原理運(yùn)行期生成接口的代理實(shí)現(xiàn)類運(yùn)行期生成目標(biāo)類的子類依賴JDK內(nèi)置無(wú)需額外依賴需要asm等字節(jié)碼庫(kù)被final修飾的方法可以正常工作無(wú)法被代理性能較高生成代理類輕量稍重創(chuàng)建代理時(shí)需生成子類字節(jié)碼實(shí)際工作中最常見(jiàn)的動(dòng)態(tài)代理應(yīng)用場(chǎng)景就是Spring AOP。比如你給一個(gè)Service方法加TransactionalSpring容器里的bean不再是原來(lái)的UserServiceImpl對(duì)象而是它的代理對(duì)象。調(diào)用方拿到的引用指向代理代理在執(zhí)行業(yè)務(wù)方法前開(kāi)啟事務(wù)方法拋異常時(shí)回滾正常結(jié)束時(shí)提交。理解了這套機(jī)制后面排查事務(wù)失效問(wèn)題就多了一把鑰匙如果某個(gè)類里的私有方法加了Transactional或者一個(gè)方法內(nèi)部直接this調(diào)用同類的另一個(gè)方法這些都不會(huì)經(jīng)過(guò)代理對(duì)象事務(wù)注解自然無(wú)效。最后提一個(gè)面試愛(ài)問(wèn)的延伸點(diǎn)為什么Spring的注解驅(qū)動(dòng)事務(wù)只對(duì)public方法生效因?yàn)镴DK動(dòng)態(tài)代理和CGLIB代理只能在方法被外部調(diào)用時(shí)攔截而this內(nèi)部調(diào)用不會(huì)經(jīng)過(guò)代理同時(shí)CGLIB生成子類時(shí)private方法不會(huì)被子類覆蓋final方法也不行。所以Spring要求事務(wù)方法必須是public且從外部調(diào)用才能被增強(qiáng)。我個(gè)人覺(jué)得動(dòng)態(tài)代理這部分不用背源碼核心就是把代理“在調(diào)用鏈上插入邏輯”這個(gè)思想想明白。代理對(duì)象和被代理對(duì)象的關(guān)系就像中介和房東租客以為自己在跟房東打交道其實(shí)合同走的是中介。中間那層中介能幫你做驗(yàn)證、記賬、協(xié)調(diào)還能隨時(shí)決定這單生意要不要做。理解了這個(gè)場(chǎng)景后面看各種框架的攔截器、過(guò)濾器時(shí)都會(huì)順暢很多。