與Redis實(shí)戰(zhàn))
先說明一下這套整理不是從網(wǎng)上隨便拼出來的“答案速查”而是我結(jié)合自己作為Java面試官的篩選邏輯、以及在真實(shí)項(xiàng)目里踩過的坑把“高頻題”和“解題思路”一起串起來了。你如果只想背八股文它也能用但更建議你在看每道題時(shí)多問一層“為什么”面試官真正想確認(rèn)的往往是你有沒有建立自己的技術(shù)判斷力。做了幾年Java開發(fā)也換過幾家公司我自己既被面試過也坐到過面試官那一邊。Java面試題翻來覆去其實(shí)就那些類目但很多人復(fù)習(xí)時(shí)只會(huì)背結(jié)論一到追問就露餡。這篇文章我會(huì)把近幾年最高頻的Java高級工程師面試題、標(biāo)準(zhǔn)答案以及答案背后的原理和排查思路全部攤開講爭取讓你看完之后不只是“記住了”而是“想通了”。內(nèi)容主要覆蓋Java基礎(chǔ)語法與集合、JVM內(nèi)存與調(diào)優(yōu)、并發(fā)編程與鎖、Redis與框架實(shí)戰(zhàn)、還有高頻的環(huán)境與編碼問題。每一塊我都按“面試官問什么”、“該怎么答”、“追問怎么接”三層來寫部分內(nèi)容附上可以直接用的命令、配置和代碼片段。適合準(zhǔn)備跳槽的Java工程師也適合剛?cè)胄邢虢⑾到y(tǒng)知識體系的新人。1. Java基礎(chǔ)面試題——代碼功底的高頻考點(diǎn)1.1 集合類框架ArrayList、LinkedList與HashMap的選型邏輯面試官問集合幾乎必問“ArrayList和LinkedList有什么區(qū)別”接著就會(huì)問HashMap的底層實(shí)現(xiàn)。這兩題聽起來基礎(chǔ)但我見過很多工作三五年的人答不全。先說ArrayList和LinkedList。ArrayList底層是Object數(shù)組查詢快是因?yàn)殡S機(jī)訪問直接按下標(biāo)定位時(shí)間復(fù)雜度O(1)但插入和刪除尤其是從中間插需要把后面的元素整體后移平均時(shí)間復(fù)雜度O(n)。LinkedList底層是雙向鏈表插入刪除只需要修改前后節(jié)點(diǎn)的引用看起來是O(1)但這個(gè)復(fù)雜度是有前提的——你要已經(jīng)持有對應(yīng)節(jié)點(diǎn)的引用。如果按索引插入LinkedList依然要遍歷到那個(gè)位置復(fù)雜度還是O(n)而且鏈表節(jié)點(diǎn)還要額外存兩份指針內(nèi)存占用比數(shù)組更大。所以實(shí)際項(xiàng)目里絕大多數(shù)場景用ArrayList就夠了LinkedList能發(fā)揮優(yōu)勢的場景相當(dāng)少。再來看HashMap這題深度可以差出很多?；A(chǔ)答案是數(shù)組加鏈表加紅黑樹默認(rèn)容量16負(fù)載因子0.75鏈表長度超過8且數(shù)組長度大于等于64時(shí)轉(zhuǎn)紅黑樹。為什么是0.75這是時(shí)間成本和空間成本的一個(gè)折中0.75意味著數(shù)組用到四分之三就擴(kuò)容比1更不容易產(chǎn)生長鏈表又比0.5更節(jié)省內(nèi)存。轉(zhuǎn)紅黑樹為什么定8根據(jù)泊松分布在負(fù)載因子0.75的情況下一個(gè)桶里鏈表長度達(dá)到8的概率已經(jīng)極低大約是千萬分之六所以閾值定在8是“概率學(xué)上的安全邊界”。面試官一旦追問“為什么容量是2的冪”這里就有關(guān)鍵原理。因?yàn)镠ashMap計(jì)算元素落點(diǎn)用的是(n - 1) hash如果n是2的冪n-1的二進(jìn)制就是低位全1與運(yùn)算的結(jié)果等價(jià)于取模但性能遠(yuǎn)高于取模擴(kuò)容時(shí)舊元素搬家也只需要看高位新增的那個(gè)bit是0還是1是0留在原位置是1就移動(dòng)到“原位置舊容量”這個(gè)設(shè)計(jì)非常精巧。我面試時(shí)如果候選人能答到這一步基本確認(rèn)他對集合是有真實(shí)理解的。1.2 異常體系與受檢異常、非受檢異常的實(shí)際選擇跟集合題同樣高頻的是Java異常體系。“Error和Exception有什么區(qū)別”“受檢異常和運(yùn)行時(shí)異常怎么選”幾乎是送分題但很多人答得模棱兩可。Java把可拋出的東西分成兩大類Error和Exception兩者都繼承自Throwable。Error是JVM層面的嚴(yán)重問題比如OutOfMemoryError、StackOverflowError程序本身處理不了不應(yīng)該試圖catch后繼續(xù)運(yùn)行。Exception才是代碼層面可以預(yù)期、可以恢復(fù)的問題。Exception又分成受檢異常和運(yùn)行時(shí)異常受檢異常如IOException、SQLException編譯期強(qiáng)制你處理要么try/catch要么throws運(yùn)行時(shí)異常如NullPointerException、IllegalArgumentException編譯期不檢查運(yùn)行到那行才可能爆出來。面試官會(huì)進(jìn)一步問你寫業(yè)務(wù)代碼時(shí)應(yīng)該用哪種我的答案是自定義業(yè)務(wù)異常比如參數(shù)校驗(yàn)失敗、資源不存在這類問題用運(yùn)行時(shí)異常更合適。理由很簡單如果在Service層到處聲明throwsController層也得跟著處理方法簽名會(huì)被異常聲明污染寫起來非常啰嗦。受檢異常適合留給那些“調(diào)用方必須處理”的資源型操作比如文件讀取、網(wǎng)絡(luò)連接因?yàn)槟悴惶幚碣Y源就漏了。熱搜詞里出現(xiàn)過uncaught exception java.lang.noclassdeffounderror: java/applet/applet in thread這類報(bào)錯(cuò)這其實(shí)就屬于NoClassDefFoundError——類定義缺失。它是Error不是Exception說明JVM在加載某個(gè)類時(shí)找不到依賴的類。它在老項(xiàng)目里常遇到原因是JDK 9以后的模塊化把Java Applet相關(guān)的類從默認(rèn)加載列表里移除了代碼里用了AWT的Applet類但沒引入依賴運(yùn)行時(shí)就拋Error。遇到這種情況別在代碼層面瞎try/catch先檢查依賴完整性和JDK版本兼容性。1.3 泛型與類型擦除為什么運(yùn)行時(shí)不關(guān)心Fish還是Dog泛型也是高頻區(qū)?！癑ava泛型是怎么實(shí)現(xiàn)的”標(biāo)準(zhǔn)答案是類型擦除泛型信息只存在于編譯期編譯完成后源碼里的ListString和ListInteger在字節(jié)碼層面都變成原始類型List運(yùn)行時(shí)無法通過反射拿到真正的泛型參數(shù)類型。這時(shí)我常會(huì)追問那為什么下面的代碼能通過反射讀取泛型很多時(shí)候候選人就卡住了。其實(shí)擦除不是把信息全刪掉類上定義的泛型信息會(huì)以Signature屬性的形式留在字節(jié)碼里比如一個(gè)類聲明了class UserDaoT那么T的信息會(huì)保留在Signature中所以Spring在注入時(shí)才能通過反射把真實(shí)類型解析出來。而方法參數(shù)里的泛型比如方法(ListString list)這個(gè)String信息會(huì)以局部變量表里的簽名形式保留所以有些框架能讀方法參數(shù)的泛型。真正會(huì)被完全擦掉的是方法內(nèi)部的局部泛型變量。除了原理面試官很喜歡問“泛型能不能用于數(shù)組”比如new T[10]能不能寫。不能因?yàn)镴ava的數(shù)組是協(xié)變的String[]是Object[]的子類運(yùn)行時(shí)能檢查對象實(shí)際類型但泛型靠擦除實(shí)現(xiàn)運(yùn)行時(shí)信息不完整如果允許泛型數(shù)組違法存儲數(shù)組存儲會(huì)破壞類型安全所以編譯器直接禁止。實(shí)際要存泛型內(nèi)容可以用ArrayListT代替數(shù)組或者用反射創(chuàng)建泛型數(shù)組但那屬于繞彎不建議。1.4 Lambda表達(dá)式與函數(shù)式接口變量捕獲的隱藏規(guī)則Java 8以后Lambda基本是必考。面試官會(huì)問“Lambda表達(dá)式能訪問外部的哪些變量”。要答到點(diǎn)子上Lambda里只能訪問被final修飾的局部變量或者實(shí)際上不可被修改的變量也就是常說的“effectively final”。為什么因?yàn)長ambda底層會(huì)把這部分變量復(fù)制到lambda對應(yīng)的匿名類里如果變量后面還被修改復(fù)制品和原來的值就對不上了容易產(chǎn)生難以定位的并發(fā)和副效應(yīng)問題。這不是語法限制而是Java為了確保行為可預(yù)測做的設(shè)計(jì)。我還遇到過面試官問“Lambda和匿名內(nèi)部類的區(qū)別”除了寫法簡潔更本質(zhì)的是作用域。匿名內(nèi)部類里如果你有一個(gè)和外部同名的變量內(nèi)部類會(huì)“遮蔽”外部變量用this.xx就能感覺到它們是不同作用域Lambda沒有獨(dú)立的作用域它跟外圍方法共享作用域所以Lambda里不能聲明和局部變量同名的參數(shù)。另外匿名內(nèi)部類會(huì)生成獨(dú)立的class文件Lambda則通過 invokedynamic 動(dòng)態(tài)生成JVM可以利用這一點(diǎn)做更多運(yùn)行期優(yōu)化這就是為什么很多地方說Lambda性能優(yōu)于匿名內(nèi)部類。2. JVM與內(nèi)存管理高頻面試題——高級工程師的必考分水嶺2.1 內(nèi)存區(qū)域劃分與OutOfMemoryError定位思路JVM這關(guān)過不了高級工程師基本沒戲。第一問通常是“JVM內(nèi)存區(qū)域怎么劃分”。答的時(shí)候要區(qū)分線程私有和線程共享線程私有的有虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器線程共享的有堆、方法區(qū)JDK 8之后是元空間、直接內(nèi)存往往不算在JVM堆內(nèi)。程序計(jì)數(shù)器是唯一不會(huì)OutOfMemoryError的區(qū)域因?yàn)槊織l線程的程序計(jì)數(shù)器空間是固定的。堆是對象分配的主戰(zhàn)場也是垃圾回收的主要區(qū)域。老年代和新生代的比例默認(rèn)是2:1新生代內(nèi)部Eden區(qū)、Survivor0、Survivor1默認(rèn)是8:1:1。為什么要兩塊Survivor因?yàn)橐械胤綍捍妗敖?jīng)歷過一次Minor GC還沒死”的對象同時(shí)也是為了減少碎片化。虛擬機(jī)棧才真正對應(yīng)我們常說的“棧”每個(gè)方法調(diào)用就是一個(gè)棧幀局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口都放在棧幀里。棧深度超過JVM默認(rèn)限制就拋StackOverflowError大多數(shù)情況下是遞歸沒有出口或者方法調(diào)用鏈路太深?？礋崴言~里的java: outofmemoryerror: insufficient memory這類堆內(nèi)存不足特別常見。排查先分兩步是堆不夠還是系統(tǒng)層面內(nèi)存不夠還是元空間不夠。堆不夠通常是對象量太大或存在泄漏先用jstat看各區(qū)域使用率再用jmap -dump導(dǎo)出堆快照用MAT或JProfiler分析對象引用鏈如果是元空間不夠多半是CGLib動(dòng)態(tài)類生成太多或者反射太頻繁適度調(diào)大-XX:MetaspaceSize可以緩解但根治還得從代碼層面減少動(dòng)態(tài)類。注意別一上來就盲目加-Xmx如果系統(tǒng)物理內(nèi)存本身就緊張加堆內(nèi)存反而把操作系統(tǒng)頁交換拖慢GC停頓更明顯。2.2 GC機(jī)制、回收器選型與三色標(biāo)記GC相關(guān)的常見問題有“怎么判斷對象可以被回收”“講一下CMS和G1區(qū)別”“你的項(xiàng)目用的什么回收器”。判斷對象是否存活標(biāo)準(zhǔn)答案是可達(dá)性分析從GC Roots出發(fā)按照引用鏈走不到的對象就是可回收的。GC Roots包括虛擬機(jī)棧中引用的對象、靜態(tài)屬性引用的對象、常量引用的對象、JNI引用的對象等。有些候選人會(huì)答引用計(jì)數(shù)需要指出引用計(jì)數(shù)解決不了循環(huán)引用問題JVM用的不是它。CMS和G1的區(qū)別是重點(diǎn)。CMS以最短停頓為目標(biāo)老年代回收采用標(biāo)記清除算法會(huì)有碎片化問題G1則是把堆劃分成多個(gè)Region既可以回收年輕代也可以回收老年代用可預(yù)期停頓模型和復(fù)制算法優(yōu)化了碎片和停頓。面試常追問“CMS并發(fā)階段怎么處理漏標(biāo)問題”這里就引出了三色標(biāo)記白色是沒訪問過的對象灰色是正在訪問的對象黑色是自身和引用都處理完的對象。并發(fā)標(biāo)記時(shí)如果黑色對象直接引用了白色對象而且灰色對象到該白色對象的引用被切斷這個(gè)白色對象會(huì)被漏標(biāo)。CMS用增量更新的方式記錄新增引用G1用SATBSnapshot At The Beginning方式記錄刪除引用兩種思路各有取舍。我自己的項(xiàng)目里JDK 8用CMSJDK 11以上直接切G1。不是CMS不好而是長期維護(hù)成本高碎片問題要注意遇到大對象分配失敗的Full GC概率會(huì)增加。G1調(diào)優(yōu)主要關(guān)注-XX:MaxGCPauseMillis目標(biāo)停頓一般設(shè)置在100到200毫秒之間設(shè)得太小會(huì)導(dǎo)致垃圾回收過于頻繁反而降低吞吐量。2.3 生產(chǎn)環(huán)境JVM排查常用指令與調(diào)優(yōu)參數(shù)這個(gè)題實(shí)踐性很強(qiáng)。面試官會(huì)問“線上JVM CPU飆升怎么排查”標(biāo)準(zhǔn)答案要包括這些步驟先用top找到CPU高的進(jìn)程再用top -Hp 進(jìn)程號找到CPU高的線程接著把線程號轉(zhuǎn)成十六進(jìn)制jstack導(dǎo)出線程快照搜索十六進(jìn)制線程號定位到具體代碼行。很多人會(huì)背這一步但實(shí)際操作中要注意jstack抓出來的線程號前綴需要自己去匹配而且抓快照最好連續(xù)抓幾次看同一線程是不是多次出現(xiàn)這樣判斷才靠譜。調(diào)優(yōu)參數(shù)我有幾個(gè)常用模板。堆內(nèi)存起步: -Xms4g -Xmx4g等價(jià)于起始值和最大值一致避免運(yùn)行期動(dòng)態(tài)擴(kuò)容帶來的性能抖動(dòng)新生代大小可以-Xmn1g或者設(shè)置-XX:NewRatio2讓老年代占三分之二OOM要留下線索必須加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/路徑/日志.hprof。元空間-XX:MetaspaceSize建議設(shè)個(gè)初始值比如256m這樣JVM啟動(dòng)時(shí)就能預(yù)留比較充足的元空間減少運(yùn)行期擴(kuò)容次數(shù)。GC日志JDK 8用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/路徑/gc.logJDK 11之后統(tǒng)一用-Xlog:gc*:filegc.log。這些參數(shù)看起來基礎(chǔ)但很多線上故障就是因?yàn)闆]有留日志、沒有開OOM dump導(dǎo)致事后連現(xiàn)場都沒有。我通常建議基礎(chǔ)服務(wù)在發(fā)布腳本里默認(rèn)把這些參數(shù)帶上代價(jià)很小排查問題時(shí)價(jià)值極大。3. 并發(fā)編程與鎖面試題——進(jìn)大廠的核心分水嶺3.1 synchronized與ReentrantLock鎖升級、AQS與公平性并發(fā)題能篩掉很多人。第一波問題通常是“synchronized底層原理是什么”“和ReentrantLock怎么選”。synchronized從JDK 6之后不再是“重型鎖”的代名詞它有鎖升級的過程無鎖、偏向鎖、輕量級鎖、重量級鎖。偏向鎖解決的是“只有一個(gè)線程反復(fù)獲取鎖”的場景一旦出現(xiàn)競爭升級為輕量級鎖通過CAS自旋嘗試拿鎖自旋超過閾值或者競爭激烈升級為重量級鎖線程掛起進(jìn)入操作系統(tǒng)內(nèi)核態(tài)等待。JDK 15之后逐步廢棄偏向鎖因?yàn)楝F(xiàn)代應(yīng)用線程競爭往往沒那么單純偏向鎖的撤銷成本甚至比收益還高。ReentrantLock則基于AbstractQueuedSynchronizerAQS實(shí)現(xiàn)。AQS內(nèi)部維護(hù)一個(gè)volatile的state變量和一個(gè)雙向等待隊(duì)列加鎖就是通過CAS把state從0改成1失敗了就進(jìn)入等待隊(duì)列掛起。為什么ReentrantLock能重入因?yàn)橥粋€(gè)線程再次加鎖時(shí)state不是從0改成1而是在原基礎(chǔ)上加1解鎖時(shí)再減回去所以叫可重入。ReentrantLock比synchronized多的能力是可中斷地等待鎖、支持超時(shí)獲取鎖、支持公平鎖、支持多個(gè)條件隊(duì)列。公平鎖和非公平鎖的區(qū)別在于非公平鎖在加鎖時(shí)先直接CAS搶一次搶不到才進(jìn)隊(duì)列公平鎖嚴(yán)格按請求順序排隊(duì)。非公平鎖吞吐量更高因?yàn)闇p少了線程掛起喚醒的開銷但可能出現(xiàn)“插隊(duì)”造成的饑餓。答最后一題我一般會(huì)給個(gè)選擇建議能用synchronized優(yōu)先synchronized因?yàn)閷懛ê唵?、JVM自動(dòng)優(yōu)化需要超時(shí)中斷、公平性、多條件隊(duì)列時(shí)再考慮ReentrantLock。3.2 volatile與可見性、重排序問題volatile是必考題但它常被誤解。volatile解決的是多線程下的可見性和有序性問題它不保證原子性。可見性靠的是JMM的happens-before規(guī)則以及緩存一致性協(xié)議有序性靠的是禁止編譯器和CPU重排序。為什么volatile int count做count還是線程不安全因?yàn)閏ount包含三步讀、加、寫volatile保證每一步之間其它線程能看到最新值但三步作為一個(gè)整體不具備原子性兩個(gè)線程可能同時(shí)讀到相同舊值各自加一寫回結(jié)果少加了一次。正確用法是普通狀態(tài)標(biāo)志用volatile比如volatile boolean running true另一個(gè)線程讀它判斷是否終止或者Double-Checked Locking單例模式里instance字段必須加volatile防止指令重排序?qū)е履玫轿闯跏蓟瓿傻膶ο?。不加volatile的DCL單例在極端并發(fā)下會(huì)出現(xiàn)拿到半初始化對象的問題這是面試官最喜歡追問的安全點(diǎn)。延伸的問題是“volatile能防止重排序嗎”要解釋內(nèi)存屏障。JMM在volatile讀寫前后插入StoreStore、StoreLoad、LoadLoad、LoadLoad等屏障限制處理器和編譯器不能把屏障兩側(cè)的指令隨意越過。這個(gè)點(diǎn)如果能畫個(gè)簡單的屏障示意或者舉一個(gè)單例初始化的例子面試官基本就滿意了。3.3 線程池的核心參數(shù)與拒絕策略“線程池的核心參數(shù)有哪些”這個(gè)問題10個(gè)人里8個(gè)人能背出來但追問“核心線程數(shù)怎么設(shè)置”就卡住了。ThreadPoolExecutor有七個(gè)參數(shù)核心線程數(shù)、最大線程數(shù)、空閑存活時(shí)間、時(shí)間單位、工作隊(duì)列、線程工廠、拒絕策略。核心線程數(shù)設(shè)置沒有銀彈CPU密集型推薦核心數(shù)1IO密集型推薦核心數(shù)*2左右還要結(jié)合壓測結(jié)果調(diào)整。關(guān)鍵理解是提交任務(wù)時(shí)如果線程數(shù)小于核心線程數(shù)直接創(chuàng)建線程如果等于核心線程數(shù)任務(wù)先進(jìn)隊(duì)列隊(duì)列滿了才創(chuàng)建額外線程直到最大線程數(shù)最大線程數(shù)和隊(duì)列都滿了觸發(fā)拒絕策略。拒絕策略有四種AbortPolicy默認(rèn)直接拋異常、CallerRunsPolicy讓提交任務(wù)的線程自己跑、DiscardPolicy靜默丟棄、DiscardOldestPolicy丟棄最老的任務(wù)。我在訂單類系統(tǒng)里通常用CallerRunsPolicy因?yàn)閷幙勺屘峤痪€程慢一點(diǎn)也不允許消息丟。還有個(gè)細(xì)節(jié)是線程池“預(yù)熱”核心線程默認(rèn)不會(huì)預(yù)先創(chuàng)建而是在有任務(wù)時(shí)創(chuàng)建如果希望提前創(chuàng)建要調(diào)用prestartAllCoreThreads()。網(wǎng)上很多文章推薦用Executors的靜態(tài)方法但阿里規(guī)約和絕大多數(shù)主流團(tuán)隊(duì)都反對。原因很直接Executors.newFixedThreadPool和newSingleThreadExecutor用的是無界LinkedBlockingQueue隊(duì)列可以無限長最大線程數(shù)形同虛設(shè)任務(wù)堆積時(shí)有內(nèi)存耗盡風(fēng)險(xiǎn)newCachedThreadPool最大線程數(shù)是Integer.MAX_VALUE高并發(fā)下可能創(chuàng)建出天文數(shù)字的線程直接拖垮機(jī)器。所以使用線程池一定手動(dòng)new ThreadPoolExecutor并明確設(shè)置隊(duì)列大小和拒絕策略。4. 常用組件與框架實(shí)戰(zhàn)高頻問題——Redis、Spring與常見故障排查4.1 RedisTemplate的increment()報(bào)錯(cuò)ERR value is not an integer or out of range這個(gè)報(bào)錯(cuò)在熱搜詞里出現(xiàn)了也是我實(shí)際被問過很多次的問題。很多人在Spring Boot里用RedisTemplate操作Redis計(jì)數(shù)器調(diào)increment()時(shí)觸發(fā)ERR value is not an integer or out of range。原因是Redis的INCR命令要求key對應(yīng)的value必須是能被解釋為整數(shù)的字符串如果value不是數(shù)字字符串比如之前用set(count, abc)或者保存了一個(gè)JSON串再執(zhí)行increment就會(huì)報(bào)錯(cuò)。還有一種更隱蔽的情況value是用StringRedisSerializer序列化寫入的整數(shù)但讀取時(shí)RedisTemplate卻用了JDK序列化器兩邊序列化方式不一致導(dǎo)致存進(jìn)去的字節(jié)數(shù)據(jù)根本不是純文本數(shù)字。排查步驟建議這么走先redis-cli連上Redis敲get 你的key看value長什么樣。如果是亂碼基本是序列化器不一致檢查RedisTemplate的keySerializer、valueSerializer和HashKeySerializer等是否都配成統(tǒng)一方案如果是“abc”這類非數(shù)字內(nèi)容說明代碼里曾經(jīng)用set方法寫入過非數(shù)字值需要清理這個(gè)key或者換一個(gè)全新的key再increment。我個(gè)人的習(xí)慣是RedisTemplate統(tǒng)一配置String序列化所有存儲的value都要自己能確認(rèn)格式尤其計(jì)數(shù)器這種需要原子自增的字段從頭到尾只通過increment操作不允許用set/append去改這樣能從源頭避免類型混亂。有一點(diǎn)容易忽略increment()的返回值是Long如果你把它強(qiáng)轉(zhuǎn)成Integer數(shù)值超過Integer范圍會(huì)直接拋異常。這也是“不是integer or out of range”里out of range的一部分原因。實(shí)際操作時(shí)計(jì)數(shù)器超過21億是很常見的比如訂單號、訪問量統(tǒng)計(jì)Long才是穩(wěn)妥的類型。4.2 Lombok版本導(dǎo)致的編譯失敗You arent using a compiler supported by lombokjava: You arent using a compiler supported by lombok, so lombok will not work是另一個(gè)高頻報(bào)錯(cuò)。這類問題大多出現(xiàn)在升級JDK或換編譯環(huán)境之后Lombok通過JDK內(nèi)部的注解處理器接口修改抽象語法樹JDK版本一變Lombok不識別新編譯器的內(nèi)部API就直接罷工。常見于JDK 16、JDK 17剛發(fā)布那陣子或者IDE自帶編譯器與項(xiàng)目JDK版本不一致。解決辦法不復(fù)雜先確認(rèn)項(xiàng)目JDK版本再上Maven倉庫查對應(yīng)Lombok版本JDK 8用1.18.20及以下JDK 11需要1.18.20JDK 16需要1.18.22JDK 17需要1.18.24JDK 21建議1.18.30。然后升級依賴并注意Maven編譯插件里如果配置了annotationProcessorPaths也要把lombok的版本同步更新只改dependency版本、不改annotationProcessorPaths會(huì)依然報(bào)錯(cuò)。IDEA里還要檢查Settings - Build - Compiler - Annotation Processors是否開啟否則即使依賴對了IDE內(nèi)啟動(dòng)也還是編譯不過。還有個(gè)小坑是把Lombok用在了JDK 8項(xiàng)目里且版本過新比如1.18.30在JDK 8環(huán)境下有時(shí)反而不兼容所以別盲目追求“新版”結(jié)合JDK選版本才是關(guān)鍵。實(shí)在不想升級包也可以把Data/Slf4j等注解手動(dòng)改寫成getter/setter/logger聲明但工作量不小不推薦長期這樣干。4.3 大寫字母開頭的Bean變量被JSON序列化變小寫的坑項(xiàng)目里經(jīng)常遇到實(shí)體類字段是private String URL;用Jackson或Spring默認(rèn)消息轉(zhuǎn)換器轉(zhuǎn)JSON后前端拿到的字段變成url結(jié)果聯(lián)調(diào)對不上字段名。原因是JavaBeans規(guī)范里有“Introspector.decapitalize”規(guī)則如果屬性名的前兩個(gè)字母都是大寫B(tài)ean屬性名會(huì)被按“原始字符串”處理如果只有第一個(gè)字母是大寫第二個(gè)字母小寫則第一個(gè)字母會(huì)被轉(zhuǎn)成小寫。URL這個(gè)字段兩個(gè)字母全大寫規(guī)則正好不會(huì)把它變小寫但更常見的坑是uRL這種不規(guī)范的命名會(huì)被解析成uRL或者URL在某些Jackson版本下也確實(shí)會(huì)被處理成url不同庫實(shí)現(xiàn)細(xì)節(jié)不一致。這個(gè)問題在網(wǎng)上常被歸為“Jackson坑”本質(zhì)是JavaBean命名規(guī)則與JSON字段命名之間的映射沖突。解決手段有這么幾種字段上用JsonProperty(URL)強(qiáng)制指定序列化名稱或者在getter方法上標(biāo)注JsonProperty(URL)也可以全局配置PropertyNamingStrategy但那會(huì)影響所有字段的命名一般不建議。更重要的是從規(guī)范層面禁止這種字段命名Java駝峰式命名法首字母小寫后面單詞首字母大寫url就寫成url如果是常量用大寫加下劃線。實(shí)體類里冒出大寫開頭字段往往是歷史代碼從C#或數(shù)據(jù)庫字段直接平移過來的習(xí)慣需要靠代碼規(guī)范去約束。4.4 Java枚舉類型、反射與Reflection的常見考點(diǎn)枚舉看起來簡單但面試官能從它問出一串高級知識點(diǎn)?；A(chǔ)問題是“枚舉的底層實(shí)現(xiàn)是什么”答案是枚舉本質(zhì)是一個(gè)繼承自java.lang.Enum的final類每個(gè)枚舉常量都是這個(gè)類的一個(gè)靜態(tài)final實(shí)例。所以枚舉天然是單例的而且線程安全這也是為什么《Effective Java》推薦用枚舉實(shí)現(xiàn)單例。追問“枚舉能不能有抽象方法”可以每個(gè)枚舉常量可以單獨(dú)實(shí)現(xiàn)抽象方法這在策略模式里很常見用一個(gè)枚舉類就能封裝多個(gè)策略。反射則往往結(jié)合Spring原理來問?！癝pring里哪里用到了反射”答案太多了Bean實(shí)例化通過反射調(diào)用構(gòu)造器依賴注入通過反射讀字段和setterAutowired、Value解析都需要反射AOP代理底層也要反射調(diào)用方法。追問“反射為什么慢”一方面是反射需要?jiǎng)討B(tài)解析方法調(diào)用編譯期優(yōu)化全部失效另一方面是要做訪問權(quán)限檢查、參數(shù)包裝等額外工作。JDK 8之后反射性能有所優(yōu)化但頻繁調(diào)用熱點(diǎn)代碼仍然不建議無腦反射能緩存Method對象就緩存能接口調(diào)用就接口調(diào)用別在循環(huán)里每次重新獲取Method。5. 高頻細(xì)節(jié)與易錯(cuò)題匯總——環(huán)境、編碼、異常排查速查5.1 Java環(huán)境變量配置與NoClassDefFoundError問題復(fù)盤環(huán)境變量這是一個(gè)非常實(shí)操的問題面試不一定問但工作中天天能遇到而且網(wǎng)上的教程經(jīng)常把人帶偏。Java環(huán)境變量主要配三個(gè)JAVA_HOME、PATH、CLASSPATH。JAVA_HOME指向JDK安裝目錄比如D:\Java\jdk1.8.0_202PATH里追加%JAVA_HOME%\bin這樣命令行才能直接識別java和javacCLASSPATH過去需要配現(xiàn)在JDK 5以后不強(qiáng)制了默認(rèn)會(huì)找當(dāng)前目錄和JRE的lib所以一般可以不用手工配置配錯(cuò)了反而會(huì)干擾類加載。熱搜詞里有個(gè)報(bào)錯(cuò)叫requires a java environment 1.5.0或者NoClassDefFoundError: java/applet/Applet這通常是電腦上裝了JRE但沒裝JDK或者JDK版本過舊缺少某些類導(dǎo)致的。還有種情況是安裝多個(gè)JDK版本PATH里先命中的是舊版項(xiàng)目用的新版命令行下運(yùn)行某個(gè)工具就用錯(cuò)了Java。我的建議是裝完JDK后先用命令java -version和javac -version確認(rèn)兩個(gè)版本一致再看echo %JAVA_HOME%確認(rèn)路徑?jīng)]有多余的尾斜杠和空格。如果命令行版本和IDE版本不一致大概率是IDE里手動(dòng)指定了JDK路徑跟系統(tǒng)PATH無關(guān)需要在IDE的Project Structure里更正。5.2 Java控制臺中文亂碼與編碼問題的排查邏輯亂碼是特別普遍的問題熱搜詞里vscode運(yùn)行Java報(bào)錯(cuò)亂碼就屬于這類。Java中文亂碼的根本原因是字符集不一致源文件編譯時(shí)用的字符集、JVM運(yùn)行時(shí)讀入字符串的字符集、控制臺或終端展示用的字符集三步中任何一步不一致就會(huì)亂碼。比如代碼文件是UTF-8但javac編譯時(shí)用的系統(tǒng)默認(rèn)字符集是GBK編譯出來的class里字符串已經(jīng)亂掉或者運(yùn)行程序時(shí)命令行沒指定-Dfile.encodingUTF-8Windows控制臺默認(rèn)GBK也會(huì)顯示亂碼。解決方案分成幾層。編譯時(shí)Maven項(xiàng)目在pom.xml里配置project.build.sourceEncoding為UTF-8Gradle項(xiàng)目在build.gradle里配置compileJava.options.encoding UTF-8。運(yùn)行時(shí)啟動(dòng)命令加-Dfile.encodingUTF-8如果是Windows控制臺要先把代碼頁切到65001或者使用IDEA的Run Configuration里設(shè)置VM options。在vscode里跑Java亂碼除了設(shè)置環(huán)境變量還要檢查lauch.json里console選項(xiàng)以及java.debug.settings.console編碼。排查亂碼我習(xí)慣寫成“三步法”先確定源文件編碼再用javac -encoding UTF-8編譯驗(yàn)證最后運(yùn)行參數(shù)加-Dfile.encodingUTF-8基本能定位到是哪一層出了問題。5.3 高頻易錯(cuò)題與基礎(chǔ)語法速查表最后一個(gè)部分我把平時(shí)最容易在筆試和一面中翻車的細(xì)節(jié)匯總成一張速查表方便面試前臨時(shí)過一遍。尤其是運(yùn)算符優(yōu)先級、數(shù)組越界、標(biāo)識符命名、排序復(fù)雜度這類零散知識點(diǎn)用表格比死記硬背更有用。易錯(cuò)點(diǎn)核心說明常見坑標(biāo)識符命名字母、下劃線、$開頭不能用數(shù)字開頭不能是關(guān)鍵字用中文或特殊符號編譯報(bào)錯(cuò)運(yùn)算符優(yōu)先級賦值最低三目次低高于||移位低于算術(shù)高于關(guān)系復(fù)雜表達(dá)式讀起來和想的完全不同數(shù)組越界ArrayIndexOutOfBoundsException索引范圍0到length-1遍歷時(shí)邊界寫成length冒泡排序平均和最壞O(n^2)最好O(n)穩(wěn)定排序忘記優(yōu)化交換標(biāo)志已有序數(shù)組還跑完整趟快速排序平均O(n log n)最壞O(n^2)不穩(wěn)定基準(zhǔn)選擇差時(shí)退化成冒泡字符串比較用equals比較內(nèi)容比較引用字符串常量池和new String混用導(dǎo)致判斷錯(cuò)誤switch支持的變量類型支持byte、short、char、int、枚舉、String不可以用long默認(rèn)值int默認(rèn)0boolean默認(rèn)false引用類型默認(rèn)null局部變量沒有默認(rèn)值不初始化直接編譯失敗位操作帶符號右移無符號右移負(fù)數(shù)右移時(shí)符號位行為不同數(shù)組越界題我曾經(jīng)在一次筆試?yán)镆娺^一個(gè)變形int[] arr new int[5];然后訪問arr[5]答案是拋數(shù)組越界但是寫arr[4]沒問題。這個(gè)確實(shí)基礎(chǔ)但很多人在寫二分查找時(shí)容易把mid的計(jì)算寫錯(cuò)導(dǎo)致死循環(huán)或越界。更實(shí)用的是記住二分查找和快速排序的邊界條件如果面試時(shí)讓手寫快排partition函數(shù)里兩個(gè)指針的交換條件必須想清楚否則最后幾步就會(huì)亂。冒泡排序的優(yōu)化也很?？技右粋€(gè)swapped標(biāo)志位如果某趟下來沒有發(fā)生任何交換就提前退出最好情況下時(shí)間復(fù)雜度能降到O(n)。面試官如果問“數(shù)組已經(jīng)有序怎么寫最快”你需要給出這個(gè)優(yōu)化版本而不是直接寫教科書版這能體現(xiàn)你有沒有在實(shí)際項(xiàng)目中關(guān)注過性能。我個(gè)人在選擇排序算法時(shí)會(huì)跟候選人確認(rèn)一個(gè)思路冒泡和快排雖然筆試考得多但Java的Arrays.sort()底層對于基本類型用的是雙軸快速排序?qū)τ趯ο箢愋陀肨imSort平時(shí)工程項(xiàng)目直接用標(biāo)準(zhǔn)庫就夠了。面試?yán)锬苁謱懣炫攀腔竟Φ嬲屛艺J(rèn)可的是能說清楚什么場景用什么排序以及為什么標(biāo)準(zhǔn)庫做了這樣取舍。再補(bǔ)充一個(gè)反射的隱含考點(diǎn)。反射和泛型經(jīng)常合起來考比如“在反射中怎么獲取List的具體泛型類型”。這個(gè)要答到ParameterizedType先通過Field.getGenericType()拿Type判斷它是不是ParameterizedType再調(diào)用getActualTypeArguments()拿真實(shí)類型。Spring的GenericTypeResolver本質(zhì)上也是做類似的事。能回答到這個(gè)層次的候選人說明確實(shí)接觸過Spring源碼級別的泛型處理而不是只會(huì)用Autowired。這里我想多說一句很多網(wǎng)上的面經(jīng)喜歡把“反射性能差”當(dāng)成死記硬背的結(jié)論但實(shí)際如果Method對象可以緩存并且不用頻繁做越權(quán)檢查反射性能并不差到不能用的程度。關(guān)鍵是把反射的適用范圍想清楚——它是框架層、通用層的利器業(yè)務(wù)代碼里能避免就避免能緩存就緩存。最后一個(gè)高頻小細(xì)節(jié)Java里String的intern()方法。它會(huì)去字符串常量池查有沒有相同內(nèi)容有就返回池里的引用沒有就放入池并返回引用。但new String(a)在運(yùn)行期構(gòu)造的對象與字符串常量池里的a不是同一個(gè)引用。這個(gè)坑在很多基礎(chǔ)筆試?yán)锓磸?fù)出現(xiàn)理解了字符串常量池之后s1 s2這類比較題基本不會(huì)做錯(cuò)。環(huán)境變量、亂碼、集合、并發(fā)、JVM這些內(nèi)容拼在一起基本覆蓋了Java高級工程師面試80%以上的高頻題。如果你準(zhǔn)備時(shí)間有限優(yōu)先吃透第2章和第3章這兩個(gè)部分幾乎決定了面試官對你的定級判斷。做完這些題目之后你會(huì)發(fā)現(xiàn)面試官追問的很多問題并不難難的是你第一次就沒把基礎(chǔ)原理梳理清楚。 Java高級工程師面試題全解析：集合、JVM、并發(fā)與Redis實(shí)戰(zhàn)
先說明一下這套整理不是從網(wǎng)上隨便拼出來的“答案速查”而是我結(jié)合自己作為Java面試官的篩選邏輯、以及在真實(shí)項(xiàng)目里踩過的坑把“高頻題”和“解題思路”一起串起來了。你如果只想背八股文它也能用但更建議你在看每道題時(shí)多問一層“為什么”面試官真正想確認(rèn)的往往是你有沒有建立自己的技術(shù)判斷力。做了幾年Java開發(fā)也換過幾家公司我自己既被面試過也坐到過面試官那一邊。Java面試題翻來覆去其實(shí)就那些類目但很多人復(fù)習(xí)時(shí)只會(huì)背結(jié)論一到追問就露餡。這篇文章我會(huì)把近幾年最高頻的Java高級工程師面試題、標(biāo)準(zhǔn)答案以及答案背后的原理和排查思路全部攤開講爭取讓你看完之后不只是“記住了”而是“想通了”。內(nèi)容主要覆蓋Java基礎(chǔ)語法與集合、JVM內(nèi)存與調(diào)優(yōu)、并發(fā)編程與鎖、Redis與框架實(shí)戰(zhàn)、還有高頻的環(huán)境與編碼問題。每一塊我都按“面試官問什么”、“該怎么答”、“追問怎么接”三層來寫部分內(nèi)容附上可以直接用的命令、配置和代碼片段。適合準(zhǔn)備跳槽的Java工程師也適合剛?cè)胄邢虢⑾到y(tǒng)知識體系的新人。1. Java基礎(chǔ)面試題——代碼功底的高頻考點(diǎn)1.1 集合類框架ArrayList、LinkedList與HashMap的選型邏輯面試官問集合幾乎必問“ArrayList和LinkedList有什么區(qū)別”接著就會(huì)問HashMap的底層實(shí)現(xiàn)。這兩題聽起來基礎(chǔ)但我見過很多工作三五年的人答不全。先說ArrayList和LinkedList。ArrayList底層是Object數(shù)組查詢快是因?yàn)殡S機(jī)訪問直接按下標(biāo)定位時(shí)間復(fù)雜度O(1)但插入和刪除尤其是從中間插需要把后面的元素整體后移平均時(shí)間復(fù)雜度O(n)。LinkedList底層是雙向鏈表插入刪除只需要修改前后節(jié)點(diǎn)的引用看起來是O(1)但這個(gè)復(fù)雜度是有前提的——你要已經(jīng)持有對應(yīng)節(jié)點(diǎn)的引用。如果按索引插入LinkedList依然要遍歷到那個(gè)位置復(fù)雜度還是O(n)而且鏈表節(jié)點(diǎn)還要額外存兩份指針內(nèi)存占用比數(shù)組更大。所以實(shí)際項(xiàng)目里絕大多數(shù)場景用ArrayList就夠了LinkedList能發(fā)揮優(yōu)勢的場景相當(dāng)少。再來看HashMap這題深度可以差出很多?；A(chǔ)答案是數(shù)組加鏈表加紅黑樹默認(rèn)容量16負(fù)載因子0.75鏈表長度超過8且數(shù)組長度大于等于64時(shí)轉(zhuǎn)紅黑樹。為什么是0.75這是時(shí)間成本和空間成本的一個(gè)折中0.75意味著數(shù)組用到四分之三就擴(kuò)容比1更不容易產(chǎn)生長鏈表又比0.5更節(jié)省內(nèi)存。轉(zhuǎn)紅黑樹為什么定8根據(jù)泊松分布在負(fù)載因子0.75的情況下一個(gè)桶里鏈表長度達(dá)到8的概率已經(jīng)極低大約是千萬分之六所以閾值定在8是“概率學(xué)上的安全邊界”。面試官一旦追問“為什么容量是2的冪”這里就有關(guān)鍵原理。因?yàn)镠ashMap計(jì)算元素落點(diǎn)用的是(n - 1) hash如果n是2的冪n-1的二進(jìn)制就是低位全1與運(yùn)算的結(jié)果等價(jià)于取模但性能遠(yuǎn)高于取模擴(kuò)容時(shí)舊元素搬家也只需要看高位新增的那個(gè)bit是0還是1是0留在原位置是1就移動(dòng)到“原位置舊容量”這個(gè)設(shè)計(jì)非常精巧。我面試時(shí)如果候選人能答到這一步基本確認(rèn)他對集合是有真實(shí)理解的。1.2 異常體系與受檢異常、非受檢異常的實(shí)際選擇跟集合題同樣高頻的是Java異常體系。“Error和Exception有什么區(qū)別”“受檢異常和運(yùn)行時(shí)異常怎么選”幾乎是送分題但很多人答得模棱兩可。Java把可拋出的東西分成兩大類Error和Exception兩者都繼承自Throwable。Error是JVM層面的嚴(yán)重問題比如OutOfMemoryError、StackOverflowError程序本身處理不了不應(yīng)該試圖catch后繼續(xù)運(yùn)行。Exception才是代碼層面可以預(yù)期、可以恢復(fù)的問題。Exception又分成受檢異常和運(yùn)行時(shí)異常受檢異常如IOException、SQLException編譯期強(qiáng)制你處理要么try/catch要么throws運(yùn)行時(shí)異常如NullPointerException、IllegalArgumentException編譯期不檢查運(yùn)行到那行才可能爆出來。面試官會(huì)進(jìn)一步問你寫業(yè)務(wù)代碼時(shí)應(yīng)該用哪種我的答案是自定義業(yè)務(wù)異常比如參數(shù)校驗(yàn)失敗、資源不存在這類問題用運(yùn)行時(shí)異常更合適。理由很簡單如果在Service層到處聲明throwsController層也得跟著處理方法簽名會(huì)被異常聲明污染寫起來非常啰嗦。受檢異常適合留給那些“調(diào)用方必須處理”的資源型操作比如文件讀取、網(wǎng)絡(luò)連接因?yàn)槟悴惶幚碣Y源就漏了。熱搜詞里出現(xiàn)過uncaught exception java.lang.noclassdeffounderror: java/applet/applet in thread這類報(bào)錯(cuò)這其實(shí)就屬于NoClassDefFoundError——類定義缺失。它是Error不是Exception說明JVM在加載某個(gè)類時(shí)找不到依賴的類。它在老項(xiàng)目里常遇到原因是JDK 9以后的模塊化把Java Applet相關(guān)的類從默認(rèn)加載列表里移除了代碼里用了AWT的Applet類但沒引入依賴運(yùn)行時(shí)就拋Error。遇到這種情況別在代碼層面瞎try/catch先檢查依賴完整性和JDK版本兼容性。1.3 泛型與類型擦除為什么運(yùn)行時(shí)不關(guān)心Fish還是Dog泛型也是高頻區(qū)?！癑ava泛型是怎么實(shí)現(xiàn)的”標(biāo)準(zhǔn)答案是類型擦除泛型信息只存在于編譯期編譯完成后源碼里的ListString和ListInteger在字節(jié)碼層面都變成原始類型List運(yùn)行時(shí)無法通過反射拿到真正的泛型參數(shù)類型。這時(shí)我常會(huì)追問那為什么下面的代碼能通過反射讀取泛型很多時(shí)候候選人就卡住了。其實(shí)擦除不是把信息全刪掉類上定義的泛型信息會(huì)以Signature屬性的形式留在字節(jié)碼里比如一個(gè)類聲明了class UserDaoT那么T的信息會(huì)保留在Signature中所以Spring在注入時(shí)才能通過反射把真實(shí)類型解析出來。而方法參數(shù)里的泛型比如方法(ListString list)這個(gè)String信息會(huì)以局部變量表里的簽名形式保留所以有些框架能讀方法參數(shù)的泛型。真正會(huì)被完全擦掉的是方法內(nèi)部的局部泛型變量。除了原理面試官很喜歡問“泛型能不能用于數(shù)組”比如new T[10]能不能寫。不能因?yàn)镴ava的數(shù)組是協(xié)變的String[]是Object[]的子類運(yùn)行時(shí)能檢查對象實(shí)際類型但泛型靠擦除實(shí)現(xiàn)運(yùn)行時(shí)信息不完整如果允許泛型數(shù)組違法存儲數(shù)組存儲會(huì)破壞類型安全所以編譯器直接禁止。實(shí)際要存泛型內(nèi)容可以用ArrayListT代替數(shù)組或者用反射創(chuàng)建泛型數(shù)組但那屬于繞彎不建議。1.4 Lambda表達(dá)式與函數(shù)式接口變量捕獲的隱藏規(guī)則Java 8以后Lambda基本是必考。面試官會(huì)問“Lambda表達(dá)式能訪問外部的哪些變量”。要答到點(diǎn)子上Lambda里只能訪問被final修飾的局部變量或者實(shí)際上不可被修改的變量也就是常說的“effectively final”。為什么因?yàn)長ambda底層會(huì)把這部分變量復(fù)制到lambda對應(yīng)的匿名類里如果變量后面還被修改復(fù)制品和原來的值就對不上了容易產(chǎn)生難以定位的并發(fā)和副效應(yīng)問題。這不是語法限制而是Java為了確保行為可預(yù)測做的設(shè)計(jì)。我還遇到過面試官問“Lambda和匿名內(nèi)部類的區(qū)別”除了寫法簡潔更本質(zhì)的是作用域。匿名內(nèi)部類里如果你有一個(gè)和外部同名的變量內(nèi)部類會(huì)“遮蔽”外部變量用this.xx就能感覺到它們是不同作用域Lambda沒有獨(dú)立的作用域它跟外圍方法共享作用域所以Lambda里不能聲明和局部變量同名的參數(shù)。另外匿名內(nèi)部類會(huì)生成獨(dú)立的class文件Lambda則通過 invokedynamic 動(dòng)態(tài)生成JVM可以利用這一點(diǎn)做更多運(yùn)行期優(yōu)化這就是為什么很多地方說Lambda性能優(yōu)于匿名內(nèi)部類。2. JVM與內(nèi)存管理高頻面試題——高級工程師的必考分水嶺2.1 內(nèi)存區(qū)域劃分與OutOfMemoryError定位思路JVM這關(guān)過不了高級工程師基本沒戲。第一問通常是“JVM內(nèi)存區(qū)域怎么劃分”。答的時(shí)候要區(qū)分線程私有和線程共享線程私有的有虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器線程共享的有堆、方法區(qū)JDK 8之后是元空間、直接內(nèi)存往往不算在JVM堆內(nèi)。程序計(jì)數(shù)器是唯一不會(huì)OutOfMemoryError的區(qū)域因?yàn)槊織l線程的程序計(jì)數(shù)器空間是固定的。堆是對象分配的主戰(zhàn)場也是垃圾回收的主要區(qū)域。老年代和新生代的比例默認(rèn)是2:1新生代內(nèi)部Eden區(qū)、Survivor0、Survivor1默認(rèn)是8:1:1。為什么要兩塊Survivor因?yàn)橐械胤綍捍妗敖?jīng)歷過一次Minor GC還沒死”的對象同時(shí)也是為了減少碎片化。虛擬機(jī)棧才真正對應(yīng)我們常說的“棧”每個(gè)方法調(diào)用就是一個(gè)棧幀局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口都放在棧幀里。棧深度超過JVM默認(rèn)限制就拋StackOverflowError大多數(shù)情況下是遞歸沒有出口或者方法調(diào)用鏈路太深?？礋崴言~里的java: outofmemoryerror: insufficient memory這類堆內(nèi)存不足特別常見。排查先分兩步是堆不夠還是系統(tǒng)層面內(nèi)存不夠還是元空間不夠。堆不夠通常是對象量太大或存在泄漏先用jstat看各區(qū)域使用率再用jmap -dump導(dǎo)出堆快照用MAT或JProfiler分析對象引用鏈如果是元空間不夠多半是CGLib動(dòng)態(tài)類生成太多或者反射太頻繁適度調(diào)大-XX:MetaspaceSize可以緩解但根治還得從代碼層面減少動(dòng)態(tài)類。注意別一上來就盲目加-Xmx如果系統(tǒng)物理內(nèi)存本身就緊張加堆內(nèi)存反而把操作系統(tǒng)頁交換拖慢GC停頓更明顯。2.2 GC機(jī)制、回收器選型與三色標(biāo)記GC相關(guān)的常見問題有“怎么判斷對象可以被回收”“講一下CMS和G1區(qū)別”“你的項(xiàng)目用的什么回收器”。判斷對象是否存活標(biāo)準(zhǔn)答案是可達(dá)性分析從GC Roots出發(fā)按照引用鏈走不到的對象就是可回收的。GC Roots包括虛擬機(jī)棧中引用的對象、靜態(tài)屬性引用的對象、常量引用的對象、JNI引用的對象等。有些候選人會(huì)答引用計(jì)數(shù)需要指出引用計(jì)數(shù)解決不了循環(huán)引用問題JVM用的不是它。CMS和G1的區(qū)別是重點(diǎn)。CMS以最短停頓為目標(biāo)老年代回收采用標(biāo)記清除算法會(huì)有碎片化問題G1則是把堆劃分成多個(gè)Region既可以回收年輕代也可以回收老年代用可預(yù)期停頓模型和復(fù)制算法優(yōu)化了碎片和停頓。面試常追問“CMS并發(fā)階段怎么處理漏標(biāo)問題”這里就引出了三色標(biāo)記白色是沒訪問過的對象灰色是正在訪問的對象黑色是自身和引用都處理完的對象。并發(fā)標(biāo)記時(shí)如果黑色對象直接引用了白色對象而且灰色對象到該白色對象的引用被切斷這個(gè)白色對象會(huì)被漏標(biāo)。CMS用增量更新的方式記錄新增引用G1用SATBSnapshot At The Beginning方式記錄刪除引用兩種思路各有取舍。我自己的項(xiàng)目里JDK 8用CMSJDK 11以上直接切G1。不是CMS不好而是長期維護(hù)成本高碎片問題要注意遇到大對象分配失敗的Full GC概率會(huì)增加。G1調(diào)優(yōu)主要關(guān)注-XX:MaxGCPauseMillis目標(biāo)停頓一般設(shè)置在100到200毫秒之間設(shè)得太小會(huì)導(dǎo)致垃圾回收過于頻繁反而降低吞吐量。2.3 生產(chǎn)環(huán)境JVM排查常用指令與調(diào)優(yōu)參數(shù)這個(gè)題實(shí)踐性很強(qiáng)。面試官會(huì)問“線上JVM CPU飆升怎么排查”標(biāo)準(zhǔn)答案要包括這些步驟先用top找到CPU高的進(jìn)程再用top -Hp 進(jìn)程號找到CPU高的線程接著把線程號轉(zhuǎn)成十六進(jìn)制jstack導(dǎo)出線程快照搜索十六進(jìn)制線程號定位到具體代碼行。很多人會(huì)背這一步但實(shí)際操作中要注意jstack抓出來的線程號前綴需要自己去匹配而且抓快照最好連續(xù)抓幾次看同一線程是不是多次出現(xiàn)這樣判斷才靠譜。調(diào)優(yōu)參數(shù)我有幾個(gè)常用模板。堆內(nèi)存起步: -Xms4g -Xmx4g等價(jià)于起始值和最大值一致避免運(yùn)行期動(dòng)態(tài)擴(kuò)容帶來的性能抖動(dòng)新生代大小可以-Xmn1g或者設(shè)置-XX:NewRatio2讓老年代占三分之二OOM要留下線索必須加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/路徑/日志.hprof。元空間-XX:MetaspaceSize建議設(shè)個(gè)初始值比如256m這樣JVM啟動(dòng)時(shí)就能預(yù)留比較充足的元空間減少運(yùn)行期擴(kuò)容次數(shù)。GC日志JDK 8用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/路徑/gc.logJDK 11之后統(tǒng)一用-Xlog:gc*:filegc.log。這些參數(shù)看起來基礎(chǔ)但很多線上故障就是因?yàn)闆]有留日志、沒有開OOM dump導(dǎo)致事后連現(xiàn)場都沒有。我通常建議基礎(chǔ)服務(wù)在發(fā)布腳本里默認(rèn)把這些參數(shù)帶上代價(jià)很小排查問題時(shí)價(jià)值極大。3. 并發(fā)編程與鎖面試題——進(jìn)大廠的核心分水嶺3.1 synchronized與ReentrantLock鎖升級、AQS與公平性并發(fā)題能篩掉很多人。第一波問題通常是“synchronized底層原理是什么”“和ReentrantLock怎么選”。synchronized從JDK 6之后不再是“重型鎖”的代名詞它有鎖升級的過程無鎖、偏向鎖、輕量級鎖、重量級鎖。偏向鎖解決的是“只有一個(gè)線程反復(fù)獲取鎖”的場景一旦出現(xiàn)競爭升級為輕量級鎖通過CAS自旋嘗試拿鎖自旋超過閾值或者競爭激烈升級為重量級鎖線程掛起進(jìn)入操作系統(tǒng)內(nèi)核態(tài)等待。JDK 15之后逐步廢棄偏向鎖因?yàn)楝F(xiàn)代應(yīng)用線程競爭往往沒那么單純偏向鎖的撤銷成本甚至比收益還高。ReentrantLock則基于AbstractQueuedSynchronizerAQS實(shí)現(xiàn)。AQS內(nèi)部維護(hù)一個(gè)volatile的state變量和一個(gè)雙向等待隊(duì)列加鎖就是通過CAS把state從0改成1失敗了就進(jìn)入等待隊(duì)列掛起。為什么ReentrantLock能重入因?yàn)橥粋€(gè)線程再次加鎖時(shí)state不是從0改成1而是在原基礎(chǔ)上加1解鎖時(shí)再減回去所以叫可重入。ReentrantLock比synchronized多的能力是可中斷地等待鎖、支持超時(shí)獲取鎖、支持公平鎖、支持多個(gè)條件隊(duì)列。公平鎖和非公平鎖的區(qū)別在于非公平鎖在加鎖時(shí)先直接CAS搶一次搶不到才進(jìn)隊(duì)列公平鎖嚴(yán)格按請求順序排隊(duì)。非公平鎖吞吐量更高因?yàn)闇p少了線程掛起喚醒的開銷但可能出現(xiàn)“插隊(duì)”造成的饑餓。答最后一題我一般會(huì)給個(gè)選擇建議能用synchronized優(yōu)先synchronized因?yàn)閷懛ê唵?、JVM自動(dòng)優(yōu)化需要超時(shí)中斷、公平性、多條件隊(duì)列時(shí)再考慮ReentrantLock。3.2 volatile與可見性、重排序問題volatile是必考題但它常被誤解。volatile解決的是多線程下的可見性和有序性問題它不保證原子性。可見性靠的是JMM的happens-before規(guī)則以及緩存一致性協(xié)議有序性靠的是禁止編譯器和CPU重排序。為什么volatile int count做count還是線程不安全因?yàn)閏ount包含三步讀、加、寫volatile保證每一步之間其它線程能看到最新值但三步作為一個(gè)整體不具備原子性兩個(gè)線程可能同時(shí)讀到相同舊值各自加一寫回結(jié)果少加了一次。正確用法是普通狀態(tài)標(biāo)志用volatile比如volatile boolean running true另一個(gè)線程讀它判斷是否終止或者Double-Checked Locking單例模式里instance字段必須加volatile防止指令重排序?qū)е履玫轿闯跏蓟瓿傻膶ο?。不加volatile的DCL單例在極端并發(fā)下會(huì)出現(xiàn)拿到半初始化對象的問題這是面試官最喜歡追問的安全點(diǎn)。延伸的問題是“volatile能防止重排序嗎”要解釋內(nèi)存屏障。JMM在volatile讀寫前后插入StoreStore、StoreLoad、LoadLoad、LoadLoad等屏障限制處理器和編譯器不能把屏障兩側(cè)的指令隨意越過。這個(gè)點(diǎn)如果能畫個(gè)簡單的屏障示意或者舉一個(gè)單例初始化的例子面試官基本就滿意了。3.3 線程池的核心參數(shù)與拒絕策略“線程池的核心參數(shù)有哪些”這個(gè)問題10個(gè)人里8個(gè)人能背出來但追問“核心線程數(shù)怎么設(shè)置”就卡住了。ThreadPoolExecutor有七個(gè)參數(shù)核心線程數(shù)、最大線程數(shù)、空閑存活時(shí)間、時(shí)間單位、工作隊(duì)列、線程工廠、拒絕策略。核心線程數(shù)設(shè)置沒有銀彈CPU密集型推薦核心數(shù)1IO密集型推薦核心數(shù)*2左右還要結(jié)合壓測結(jié)果調(diào)整。關(guān)鍵理解是提交任務(wù)時(shí)如果線程數(shù)小于核心線程數(shù)直接創(chuàng)建線程如果等于核心線程數(shù)任務(wù)先進(jìn)隊(duì)列隊(duì)列滿了才創(chuàng)建額外線程直到最大線程數(shù)最大線程數(shù)和隊(duì)列都滿了觸發(fā)拒絕策略。拒絕策略有四種AbortPolicy默認(rèn)直接拋異常、CallerRunsPolicy讓提交任務(wù)的線程自己跑、DiscardPolicy靜默丟棄、DiscardOldestPolicy丟棄最老的任務(wù)。我在訂單類系統(tǒng)里通常用CallerRunsPolicy因?yàn)閷幙勺屘峤痪€程慢一點(diǎn)也不允許消息丟。還有個(gè)細(xì)節(jié)是線程池“預(yù)熱”核心線程默認(rèn)不會(huì)預(yù)先創(chuàng)建而是在有任務(wù)時(shí)創(chuàng)建如果希望提前創(chuàng)建要調(diào)用prestartAllCoreThreads()。網(wǎng)上很多文章推薦用Executors的靜態(tài)方法但阿里規(guī)約和絕大多數(shù)主流團(tuán)隊(duì)都反對。原因很直接Executors.newFixedThreadPool和newSingleThreadExecutor用的是無界LinkedBlockingQueue隊(duì)列可以無限長最大線程數(shù)形同虛設(shè)任務(wù)堆積時(shí)有內(nèi)存耗盡風(fēng)險(xiǎn)newCachedThreadPool最大線程數(shù)是Integer.MAX_VALUE高并發(fā)下可能創(chuàng)建出天文數(shù)字的線程直接拖垮機(jī)器。所以使用線程池一定手動(dòng)new ThreadPoolExecutor并明確設(shè)置隊(duì)列大小和拒絕策略。4. 常用組件與框架實(shí)戰(zhàn)高頻問題——Redis、Spring與常見故障排查4.1 RedisTemplate的increment()報(bào)錯(cuò)ERR value is not an integer or out of range這個(gè)報(bào)錯(cuò)在熱搜詞里出現(xiàn)了也是我實(shí)際被問過很多次的問題。很多人在Spring Boot里用RedisTemplate操作Redis計(jì)數(shù)器調(diào)increment()時(shí)觸發(fā)ERR value is not an integer or out of range。原因是Redis的INCR命令要求key對應(yīng)的value必須是能被解釋為整數(shù)的字符串如果value不是數(shù)字字符串比如之前用set(count, abc)或者保存了一個(gè)JSON串再執(zhí)行increment就會(huì)報(bào)錯(cuò)。還有一種更隱蔽的情況value是用StringRedisSerializer序列化寫入的整數(shù)但讀取時(shí)RedisTemplate卻用了JDK序列化器兩邊序列化方式不一致導(dǎo)致存進(jìn)去的字節(jié)數(shù)據(jù)根本不是純文本數(shù)字。排查步驟建議這么走先redis-cli連上Redis敲get 你的key看value長什么樣。如果是亂碼基本是序列化器不一致檢查RedisTemplate的keySerializer、valueSerializer和HashKeySerializer等是否都配成統(tǒng)一方案如果是“abc”這類非數(shù)字內(nèi)容說明代碼里曾經(jīng)用set方法寫入過非數(shù)字值需要清理這個(gè)key或者換一個(gè)全新的key再increment。我個(gè)人的習(xí)慣是RedisTemplate統(tǒng)一配置String序列化所有存儲的value都要自己能確認(rèn)格式尤其計(jì)數(shù)器這種需要原子自增的字段從頭到尾只通過increment操作不允許用set/append去改這樣能從源頭避免類型混亂。有一點(diǎn)容易忽略increment()的返回值是Long如果你把它強(qiáng)轉(zhuǎn)成Integer數(shù)值超過Integer范圍會(huì)直接拋異常。這也是“不是integer or out of range”里out of range的一部分原因。實(shí)際操作時(shí)計(jì)數(shù)器超過21億是很常見的比如訂單號、訪問量統(tǒng)計(jì)Long才是穩(wěn)妥的類型。4.2 Lombok版本導(dǎo)致的編譯失敗You arent using a compiler supported by lombokjava: You arent using a compiler supported by lombok, so lombok will not work是另一個(gè)高頻報(bào)錯(cuò)。這類問題大多出現(xiàn)在升級JDK或換編譯環(huán)境之后Lombok通過JDK內(nèi)部的注解處理器接口修改抽象語法樹JDK版本一變Lombok不識別新編譯器的內(nèi)部API就直接罷工。常見于JDK 16、JDK 17剛發(fā)布那陣子或者IDE自帶編譯器與項(xiàng)目JDK版本不一致。解決辦法不復(fù)雜先確認(rèn)項(xiàng)目JDK版本再上Maven倉庫查對應(yīng)Lombok版本JDK 8用1.18.20及以下JDK 11需要1.18.20JDK 16需要1.18.22JDK 17需要1.18.24JDK 21建議1.18.30。然后升級依賴并注意Maven編譯插件里如果配置了annotationProcessorPaths也要把lombok的版本同步更新只改dependency版本、不改annotationProcessorPaths會(huì)依然報(bào)錯(cuò)。IDEA里還要檢查Settings - Build - Compiler - Annotation Processors是否開啟否則即使依賴對了IDE內(nèi)啟動(dòng)也還是編譯不過。還有個(gè)小坑是把Lombok用在了JDK 8項(xiàng)目里且版本過新比如1.18.30在JDK 8環(huán)境下有時(shí)反而不兼容所以別盲目追求“新版”結(jié)合JDK選版本才是關(guān)鍵。實(shí)在不想升級包也可以把Data/Slf4j等注解手動(dòng)改寫成getter/setter/logger聲明但工作量不小不推薦長期這樣干。4.3 大寫字母開頭的Bean變量被JSON序列化變小寫的坑項(xiàng)目里經(jīng)常遇到實(shí)體類字段是private String URL;用Jackson或Spring默認(rèn)消息轉(zhuǎn)換器轉(zhuǎn)JSON后前端拿到的字段變成url結(jié)果聯(lián)調(diào)對不上字段名。原因是JavaBeans規(guī)范里有“Introspector.decapitalize”規(guī)則如果屬性名的前兩個(gè)字母都是大寫B(tài)ean屬性名會(huì)被按“原始字符串”處理如果只有第一個(gè)字母是大寫第二個(gè)字母小寫則第一個(gè)字母會(huì)被轉(zhuǎn)成小寫。URL這個(gè)字段兩個(gè)字母全大寫規(guī)則正好不會(huì)把它變小寫但更常見的坑是uRL這種不規(guī)范的命名會(huì)被解析成uRL或者URL在某些Jackson版本下也確實(shí)會(huì)被處理成url不同庫實(shí)現(xiàn)細(xì)節(jié)不一致。這個(gè)問題在網(wǎng)上常被歸為“Jackson坑”本質(zhì)是JavaBean命名規(guī)則與JSON字段命名之間的映射沖突。解決手段有這么幾種字段上用JsonProperty(URL)強(qiáng)制指定序列化名稱或者在getter方法上標(biāo)注JsonProperty(URL)也可以全局配置PropertyNamingStrategy但那會(huì)影響所有字段的命名一般不建議。更重要的是從規(guī)范層面禁止這種字段命名Java駝峰式命名法首字母小寫后面單詞首字母大寫url就寫成url如果是常量用大寫加下劃線。實(shí)體類里冒出大寫開頭字段往往是歷史代碼從C#或數(shù)據(jù)庫字段直接平移過來的習(xí)慣需要靠代碼規(guī)范去約束。4.4 Java枚舉類型、反射與Reflection的常見考點(diǎn)枚舉看起來簡單但面試官能從它問出一串高級知識點(diǎn)?；A(chǔ)問題是“枚舉的底層實(shí)現(xiàn)是什么”答案是枚舉本質(zhì)是一個(gè)繼承自java.lang.Enum的final類每個(gè)枚舉常量都是這個(gè)類的一個(gè)靜態(tài)final實(shí)例。所以枚舉天然是單例的而且線程安全這也是為什么《Effective Java》推薦用枚舉實(shí)現(xiàn)單例。追問“枚舉能不能有抽象方法”可以每個(gè)枚舉常量可以單獨(dú)實(shí)現(xiàn)抽象方法這在策略模式里很常見用一個(gè)枚舉類就能封裝多個(gè)策略。反射則往往結(jié)合Spring原理來問?！癝pring里哪里用到了反射”答案太多了Bean實(shí)例化通過反射調(diào)用構(gòu)造器依賴注入通過反射讀字段和setterAutowired、Value解析都需要反射AOP代理底層也要反射調(diào)用方法。追問“反射為什么慢”一方面是反射需要?jiǎng)討B(tài)解析方法調(diào)用編譯期優(yōu)化全部失效另一方面是要做訪問權(quán)限檢查、參數(shù)包裝等額外工作。JDK 8之后反射性能有所優(yōu)化但頻繁調(diào)用熱點(diǎn)代碼仍然不建議無腦反射能緩存Method對象就緩存能接口調(diào)用就接口調(diào)用別在循環(huán)里每次重新獲取Method。5. 高頻細(xì)節(jié)與易錯(cuò)題匯總——環(huán)境、編碼、異常排查速查5.1 Java環(huán)境變量配置與NoClassDefFoundError問題復(fù)盤環(huán)境變量這是一個(gè)非常實(shí)操的問題面試不一定問但工作中天天能遇到而且網(wǎng)上的教程經(jīng)常把人帶偏。Java環(huán)境變量主要配三個(gè)JAVA_HOME、PATH、CLASSPATH。JAVA_HOME指向JDK安裝目錄比如D:\Java\jdk1.8.0_202PATH里追加%JAVA_HOME%\bin這樣命令行才能直接識別java和javacCLASSPATH過去需要配現(xiàn)在JDK 5以后不強(qiáng)制了默認(rèn)會(huì)找當(dāng)前目錄和JRE的lib所以一般可以不用手工配置配錯(cuò)了反而會(huì)干擾類加載。熱搜詞里有個(gè)報(bào)錯(cuò)叫requires a java environment 1.5.0或者NoClassDefFoundError: java/applet/Applet這通常是電腦上裝了JRE但沒裝JDK或者JDK版本過舊缺少某些類導(dǎo)致的。還有種情況是安裝多個(gè)JDK版本PATH里先命中的是舊版項(xiàng)目用的新版命令行下運(yùn)行某個(gè)工具就用錯(cuò)了Java。我的建議是裝完JDK后先用命令java -version和javac -version確認(rèn)兩個(gè)版本一致再看echo %JAVA_HOME%確認(rèn)路徑?jīng)]有多余的尾斜杠和空格。如果命令行版本和IDE版本不一致大概率是IDE里手動(dòng)指定了JDK路徑跟系統(tǒng)PATH無關(guān)需要在IDE的Project Structure里更正。5.2 Java控制臺中文亂碼與編碼問題的排查邏輯亂碼是特別普遍的問題熱搜詞里vscode運(yùn)行Java報(bào)錯(cuò)亂碼就屬于這類。Java中文亂碼的根本原因是字符集不一致源文件編譯時(shí)用的字符集、JVM運(yùn)行時(shí)讀入字符串的字符集、控制臺或終端展示用的字符集三步中任何一步不一致就會(huì)亂碼。比如代碼文件是UTF-8但javac編譯時(shí)用的系統(tǒng)默認(rèn)字符集是GBK編譯出來的class里字符串已經(jīng)亂掉或者運(yùn)行程序時(shí)命令行沒指定-Dfile.encodingUTF-8Windows控制臺默認(rèn)GBK也會(huì)顯示亂碼。解決方案分成幾層。編譯時(shí)Maven項(xiàng)目在pom.xml里配置project.build.sourceEncoding為UTF-8Gradle項(xiàng)目在build.gradle里配置compileJava.options.encoding UTF-8。運(yùn)行時(shí)啟動(dòng)命令加-Dfile.encodingUTF-8如果是Windows控制臺要先把代碼頁切到65001或者使用IDEA的Run Configuration里設(shè)置VM options。在vscode里跑Java亂碼除了設(shè)置環(huán)境變量還要檢查lauch.json里console選項(xiàng)以及java.debug.settings.console編碼。排查亂碼我習(xí)慣寫成“三步法”先確定源文件編碼再用javac -encoding UTF-8編譯驗(yàn)證最后運(yùn)行參數(shù)加-Dfile.encodingUTF-8基本能定位到是哪一層出了問題。5.3 高頻易錯(cuò)題與基礎(chǔ)語法速查表最后一個(gè)部分我把平時(shí)最容易在筆試和一面中翻車的細(xì)節(jié)匯總成一張速查表方便面試前臨時(shí)過一遍。尤其是運(yùn)算符優(yōu)先級、數(shù)組越界、標(biāo)識符命名、排序復(fù)雜度這類零散知識點(diǎn)用表格比死記硬背更有用。易錯(cuò)點(diǎn)核心說明常見坑標(biāo)識符命名字母、下劃線、$開頭不能用數(shù)字開頭不能是關(guān)鍵字用中文或特殊符號編譯報(bào)錯(cuò)運(yùn)算符優(yōu)先級賦值最低三目次低高于||移位低于算術(shù)高于關(guān)系復(fù)雜表達(dá)式讀起來和想的完全不同數(shù)組越界ArrayIndexOutOfBoundsException索引范圍0到length-1遍歷時(shí)邊界寫成length冒泡排序平均和最壞O(n^2)最好O(n)穩(wěn)定排序忘記優(yōu)化交換標(biāo)志已有序數(shù)組還跑完整趟快速排序平均O(n log n)最壞O(n^2)不穩(wěn)定基準(zhǔn)選擇差時(shí)退化成冒泡字符串比較用equals比較內(nèi)容比較引用字符串常量池和new String混用導(dǎo)致判斷錯(cuò)誤switch支持的變量類型支持byte、short、char、int、枚舉、String不可以用long默認(rèn)值int默認(rèn)0boolean默認(rèn)false引用類型默認(rèn)null局部變量沒有默認(rèn)值不初始化直接編譯失敗位操作帶符號右移無符號右移負(fù)數(shù)右移時(shí)符號位行為不同數(shù)組越界題我曾經(jīng)在一次筆試?yán)镆娺^一個(gè)變形int[] arr new int[5];然后訪問arr[5]答案是拋數(shù)組越界但是寫arr[4]沒問題。這個(gè)確實(shí)基礎(chǔ)但很多人在寫二分查找時(shí)容易把mid的計(jì)算寫錯(cuò)導(dǎo)致死循環(huán)或越界。更實(shí)用的是記住二分查找和快速排序的邊界條件如果面試時(shí)讓手寫快排partition函數(shù)里兩個(gè)指針的交換條件必須想清楚否則最后幾步就會(huì)亂。冒泡排序的優(yōu)化也很?？技右粋€(gè)swapped標(biāo)志位如果某趟下來沒有發(fā)生任何交換就提前退出最好情況下時(shí)間復(fù)雜度能降到O(n)。面試官如果問“數(shù)組已經(jīng)有序怎么寫最快”你需要給出這個(gè)優(yōu)化版本而不是直接寫教科書版這能體現(xiàn)你有沒有在實(shí)際項(xiàng)目中關(guān)注過性能。我個(gè)人在選擇排序算法時(shí)會(huì)跟候選人確認(rèn)一個(gè)思路冒泡和快排雖然筆試考得多但Java的Arrays.sort()底層對于基本類型用的是雙軸快速排序?qū)τ趯ο箢愋陀肨imSort平時(shí)工程項(xiàng)目直接用標(biāo)準(zhǔn)庫就夠了。面試?yán)锬苁謱懣炫攀腔竟Φ嬲屛艺J(rèn)可的是能說清楚什么場景用什么排序以及為什么標(biāo)準(zhǔn)庫做了這樣取舍。再補(bǔ)充一個(gè)反射的隱含考點(diǎn)。反射和泛型經(jīng)常合起來考比如“在反射中怎么獲取List的具體泛型類型”。這個(gè)要答到ParameterizedType先通過Field.getGenericType()拿Type判斷它是不是ParameterizedType再調(diào)用getActualTypeArguments()拿真實(shí)類型。Spring的GenericTypeResolver本質(zhì)上也是做類似的事。能回答到這個(gè)層次的候選人說明確實(shí)接觸過Spring源碼級別的泛型處理而不是只會(huì)用Autowired。這里我想多說一句很多網(wǎng)上的面經(jīng)喜歡把“反射性能差”當(dāng)成死記硬背的結(jié)論但實(shí)際如果Method對象可以緩存并且不用頻繁做越權(quán)檢查反射性能并不差到不能用的程度。關(guān)鍵是把反射的適用范圍想清楚——它是框架層、通用層的利器業(yè)務(wù)代碼里能避免就避免能緩存就緩存。最后一個(gè)高頻小細(xì)節(jié)Java里String的intern()方法。它會(huì)去字符串常量池查有沒有相同內(nèi)容有就返回池里的引用沒有就放入池并返回引用。但new String(a)在運(yùn)行期構(gòu)造的對象與字符串常量池里的a不是同一個(gè)引用。這個(gè)坑在很多基礎(chǔ)筆試?yán)锓磸?fù)出現(xiàn)理解了字符串常量池之后s1 s2這類比較題基本不會(huì)做錯(cuò)。環(huán)境變量、亂碼、集合、并發(fā)、JVM這些內(nèi)容拼在一起基本覆蓋了Java高級工程師面試80%以上的高頻題。如果你準(zhǔn)備時(shí)間有限優(yōu)先吃透第2章和第3章這兩個(gè)部分幾乎決定了面試官對你的定級判斷。做完這些題目之后你會(huì)發(fā)現(xiàn)面試官追問的很多問題并不難難的是你第一次就沒把基礎(chǔ)原理梳理清楚。