1. 2026年的Java面試,到底在考什么說句實(shí)話,每年三四月一到,后臺私信問“Java面試題怎么準(zhǔn)備”的人就格外多。2026年4月這個(gè)時(shí)間點(diǎn),我翻了一圈大家搜得最多的關(guān)鍵詞:Java基礎(chǔ)、java面試八股文、Spring Boot、MySQL、Redis、Kafka、分布式鎖,還有一堆Linux、前端Vue3、軟件測試的題也混了進(jìn)來。這說明一個(gè)很現(xiàn)實(shí)的問題:面試早就不是“背幾道題就能過”的時(shí)代了,面試官自己也進(jìn)化了,越來越喜歡往實(shí)際場景里問,追著你的回答一層一層往下挖。這篇內(nèi)容我不打算給你一份“標(biāo)準(zhǔn)答案大全”,那種資料網(wǎng)上到處都是,背完第二天就忘。我更想做的,是把當(dāng)前這個(gè)節(jié)點(diǎn)上Java面試最高頻的考點(diǎn)拆開揉碎,講講每道題背后的原理、面試官到底想聽到什么、哪些地方容易翻車,再加上我自己這些年面試別人和被別人面試攢下的一些經(jīng)驗(yàn)。不管你是準(zhǔn)備校招、跳槽,還是剛轉(zhuǎn)行想入坑Java,這篇都可以當(dāng)成一份“面試前必刷清單”來用。內(nèi)容涉及的面比較寬,包括Java基礎(chǔ)與JVM、并發(fā)編程、Spring家族、MySQL和Redis、分布式與消息隊(duì)列、算法手寫題,順帶把熱詞里的Linux、前端、測試方向也帶一下,盡量做到有代表性。需要提前說明的是,面試題沒有絕對標(biāo)準(zhǔn)的答案,同一個(gè)問題不同面試官的理解也可能不一樣。我下面整理的這些,綜合了最近招聘市場上普遍的考察套路,再加上大家搜索熱度最高的方向。你要是能在理解的基礎(chǔ)上,結(jié)合自己的項(xiàng)目經(jīng)歷給出更具體的回答,那效果會比背任何現(xiàn)成答案都好得多。2. Java基礎(chǔ)與JVM:最容易翻車的高頻區(qū)2.1 集合框架:ArrayList、HashMap源碼你真的讀懂了嗎集合是Java面試的入門必問,但很多人掛在同一個(gè)地方:只背結(jié)論,不講原理。比如面試官問“HashMap的put流程是什么”,你如果只說“根據(jù)hash找到桶位置,沖突就鏈表或紅黑樹”,這個(gè)回答只能拿及格分,拿不到亮點(diǎn)分。真正的答題思路是這樣的:先講hash算法的本質(zhì),也就是(key null) ? 0 : (h key.hashCode()) ^ (h 16),這么設(shè)計(jì)是為了讓高位與低位做異或,讓高位也參與取模運(yùn)算,從而降低哈希沖突概率。然后講put的完整流程:計(jì)算hash - 判斷table是否為空,空則先resize初始化 - 根據(jù)hash定位到桶 - 桶為空直接插入 - 桶不為空則判斷首節(jié)點(diǎn)key是否相同,相同則覆蓋 - 如果是TreeNode就按紅黑樹插入 - 否則遍歷鏈表,找到相同key就覆蓋,找不到就尾插,同時(shí)判斷鏈表長度是否達(dá)到8且table長度達(dá)到64,滿足才轉(zhuǎn)成紅黑樹。最后再補(bǔ)一句什么時(shí)候觸發(fā)resize、負(fù)載因子默認(rèn)0.75的原因。這里有個(gè)細(xì)節(jié)經(jīng)常被考:為什么鏈表轉(zhuǎn)紅黑樹的閾值是8,而紅黑樹退化為鏈表的閾值是6?網(wǎng)上有人說是“時(shí)間復(fù)雜度的平衡點(diǎn)”,其實(shí)源碼注釋里給過解釋:根據(jù)泊松分布,在負(fù)載因子0.75、隨機(jī)hash的情況下,一個(gè)桶里鏈表長度超過8的概率大約是千萬分之六,所以8是基于統(tǒng)計(jì)和性能綜合考量的經(jīng)驗(yàn)值。而退化閾值選6而不是7,是為了留出緩沖,避免鏈表和紅黑樹在邊界上來回切換,白白消耗性能。能把這個(gè)細(xì)節(jié)答出來,面試官對你的印象分立刻不一樣。ArrayList這邊,高頻考點(diǎn)是擴(kuò)容機(jī)制:默認(rèn)容量10,擴(kuò)容時(shí)newCapacity oldCapacity (oldCapacity 1),也就是原來的1.5倍。擴(kuò)容靠Arrays.copyOf,底層調(diào)用System.arraycopy這個(gè)native方法,注意這是淺拷貝。還有一個(gè)經(jīng)典對比題:ArrayList和LinkedList的區(qū)別。很多人只答“一個(gè)數(shù)組一個(gè)鏈表”,但面試官真正想聽的是三個(gè)維度:內(nèi)存結(jié)構(gòu)、增刪改查的時(shí)間復(fù)雜度、對CPU緩存的利用。ArrayList隨機(jī)訪問是O(1),LinkedList是O(n);在頭部插入上ArrayList要移動后面所有元素所以是O(n),LinkedList是O(1);但現(xiàn)代CPU有緩存行機(jī)制,ArrayList的連續(xù)內(nèi)存在遍歷時(shí)反而比LinkedList快很多,因?yàn)榭梢灶A(yù)取到緩存中。這個(gè)點(diǎn)能說出來,比單純背區(qū)別就有深度多了。2.2 JVM內(nèi)存與垃圾回收:OOM不是一句“內(nèi)存不夠”就能糊弄的熱詞里有一個(gè)非常有代表性的報(bào)錯(cuò):java: outofmemoryerror: insufficient memory。這個(gè)錯(cuò)誤在面試?yán)锝?jīng)常被包裝成場景題來考,如果你只回答“內(nèi)存不夠了,調(diào)大Xmx就行”,那基本就涼了。正確的排查思路是分層的:先確認(rèn)是堆內(nèi)存OOM還是非堆內(nèi)存OOM。堆內(nèi)存OOM要分清是Java heap space、GC overhead limit exceeded還是Metaspace。Java heap space優(yōu)先用jmap -dump:formatb,fileheap.hprof pid抓堆轉(zhuǎn)儲,然后用MAT或JProfiler分析誰占了內(nèi)存大頭,定位到具體的業(yè)務(wù)代碼場景。GC overhead limit exceeded的意思是GC回收效率太低,花了98%的時(shí)間在GC卻回收不到2%的內(nèi)存,這種情況先看代碼里是不是有循環(huán)創(chuàng)建大對象或者大List沒釋放,再看堆是不是真的設(shè)置得太小。Metaspace爆了通常是動態(tài)生成類太多,比如大量CGLIB代理、反射生成類、熱部署場景,老項(xiàng)目里最常見的就是引了太多第三方框架還沒做類加載隔離。垃圾回收這一塊,現(xiàn)在面試官的關(guān)注點(diǎn)已經(jīng)從“背CMS和G1的區(qū)別”變成了“你項(xiàng)目里用的什么回收器,為什么選它,參數(shù)怎么調(diào)的”。如果你的項(xiàng)目還在JDK 8,老老實(shí)實(shí)說G1就已經(jīng)能過關(guān);如果在JDK 17以上,可以聊聊ZGC以及JDK 21虛擬線程對GC停頓的改善,但同時(shí)得注意,不要為了顯得高深就堆概念,要結(jié)合自己的項(xiàng)目場景說:堆多大、預(yù)期的請求量級、對延遲的敏感程度,這些才是面試官真正想聽的具體內(nèi)容。熱詞里還有一個(gè)JDK編譯的坑:java: 警告: 源發(fā)行版 17 需要目標(biāo)發(fā)行版 17。這個(gè)問題在面試?yán)锱紶枙葑兂梢坏拉h(huán)境排查題:IDEA里為什么會報(bào)這個(gè)錯(cuò)?本質(zhì)上就是maven-compiler-plugin的source和target版本與當(dāng)前JDK版本不匹配,或者IDEA的Project Structure里Project SDK和Java Compiler的Target bytecode version不一致。解決辦法要么統(tǒng)一在pom.xml里配置maven.compiler.source和maven.compiler.target,要么更高階一點(diǎn),直接用release17/release來同時(shí)限定源碼和字節(jié)碼版本。這種問題雖然基礎(chǔ),但在線上面試的共享屏幕環(huán)節(jié),出鏡率真不低。2.3 String、異常、泛型與Lambda:基礎(chǔ)題也有深水區(qū)String有兩道經(jīng)典題:一是String a abc; String b new String(abc);為什么a和b用比較是false,因?yàn)榍罢咦咦址Ａ砍?后者在堆上創(chuàng)建對象。二是String為什么設(shè)計(jì)成不可變,這個(gè)要答出三點(diǎn):安全(字符串常被用作類名、網(wǎng)絡(luò)地址、配置項(xiàng),可變會帶來隱患)、常量池復(fù)用(只有不可變,才能安全地在常量池里共享對象)、線程安全(不可變對象天然線程安全,不需要額外同步)。能答出這三個(gè)層次,基本就過關(guān)了。異常這塊別只背“Error和Exception的區(qū)別”,要會畫異常分類的樹狀結(jié)構(gòu),更要會回答“什么時(shí)候用受檢異常、什么時(shí)候用非受檢異?！?。我的建議是:業(yè)務(wù)上可以恢復(fù)的、調(diào)用方必須處理的,用受檢異常;程序bug、參數(shù)錯(cuò)誤這類不可恢復(fù)的,用非受檢異常,比如IllegalArgumentException和NullPointerException。不過現(xiàn)在的項(xiàng)目里,新代碼其實(shí)已經(jīng)不怎么用受檢異常了,更多是用Result對象統(tǒng)一封裝錯(cuò)誤碼,這個(gè)趨勢在面試?yán)镆部梢粤囊涣?顯得你不僅在應(yīng)試,還在關(guān)注行業(yè)實(shí)踐演進(jìn)。泛型問得最多的是List? extends T和List? super T的區(qū)別,也就是PECS原則(Producer Extends, Consumer Super):如果你要從集合里往外讀元素,用extends;如果你要往集合里寫元素,用super。Lambda和函數(shù)式接口也是熱詞里的高頻點(diǎn),面試官喜歡問:FunctionalInterface的作用是什么、Stream的map和flatMap區(qū)別、方法引用有哪四種類型。這類題目不難,但容易答得零散,建議整理成體系來備:函數(shù)式接口 - Lambda語法 - Stream操作分類(中間操作和終止操作) - 常見的流式處理陷阱。這里有個(gè)好素材,比如parallelStream在什么場景下反而更慢——數(shù)據(jù)量小、CPU密集、有共享可變狀態(tài)時(shí),并行流的分片和合并開銷可能會抵消并行收益,這個(gè)細(xì)節(jié)說出來就會顯得你踩過坑。還有一個(gè)熱詞我特別想說:java中數(shù)組越界異常(ArrayIndexOutOfBoundsException)。乍一看太基礎(chǔ)了對吧?但它恰恰是很多中高級程序員都容易踩的坑——比如在for循環(huán)里用了i list.size()而不是i list.size(),或者多線程環(huán)境下遍歷集合的同時(shí),另一個(gè)線程正在remove元素。面試考這個(gè)往往不是考你認(rèn)識不認(rèn)識這個(gè)異常,而是考你怎么避免它:優(yōu)先用增強(qiáng)for或者Iterator,需要邊遍歷邊刪除時(shí)用Iterator.remove()而不是list.remove()。Java里也有fail-fast機(jī)制,ArrayList的modCount和迭代器的expectedModCount不一致時(shí)就會拋ConcurrentModificationException,這是另外一個(gè)?？键c(diǎn),可以串在一起準(zhǔn)備。3. 并發(fā)編程與多線程:高并發(fā)場景的核心考察點(diǎn)3.1 synchronized與ReentrantLock怎么選這道題問的人太多,但答得好的人太少。大多數(shù)人的答案停留在“synchronized是JVM層面的鎖,ReentrantLock是JDK層面的鎖”——這相當(dāng)于只說了一個(gè)字面結(jié)論,面試官想聽的是更具體的差異點(diǎn)和選型邏輯。完整的對比至少應(yīng)該包含這幾個(gè)維度。底層實(shí)現(xiàn)上,synchronized依賴Monitor監(jiān)視器,由JVM管理,而ReentrantLock基于AQS抽象隊(duì)列同步器。功能上,ReentrantLock支持可中斷獲取鎖(lockInterruptibly)、支持超時(shí)獲取鎖(tryLock(timeout))、可以指定公平策略,還能綁定多個(gè)Condition條件隊(duì)列實(shí)現(xiàn)分組喚醒,這些synchronized都不支持。性能上,經(jīng)過長期優(yōu)化,synchronized有了偏向鎖、輕量級鎖、重量級鎖的升級路徑,和ReentrantLock在普通競爭下的性能差距已經(jīng)非常小,所以我的選型原則是:如果沒有中斷、超時(shí)、公平鎖、多條件隊(duì)列這些高級需求,直接優(yōu)先用synchronized,代碼更簡潔,也不會犯“l(fā)ock后忘記unlock導(dǎo)致死鎖”的低級錯(cuò)誤。如果面試官繼續(xù)往下追AQS的原理,你應(yīng)該能說清楚這幾個(gè)點(diǎn):AQS內(nèi)部維護(hù)一個(gè)volatile的state變量和一個(gè)基于CLH變體的FIFO雙向等待隊(duì)列。acquire方法先嘗試tryAcquire修改state,失敗就把當(dāng)前線程封裝成Node節(jié)點(diǎn)放入隊(duì)尾,并通過LockSupport.park掛起線程;釋放鎖時(shí)喚醒head節(jié)點(diǎn)的后繼線程。ReentrantLock的可重入是怎么實(shí)現(xiàn)的?就是當(dāng)前線程再次獲取鎖時(shí)state自增,釋放鎖時(shí)state自減,減到0才真正釋放鎖。這個(gè)機(jī)制聽起來簡單,卻是整個(gè)JUC并發(fā)包的基石,值得花時(shí)間吃透。3.2 volatile、CAS、ThreadLocal的原理與坑volatile有“三必問”:保證可見性、禁止指令重排、不保證原子性。前兩個(gè)是它存在的意義,第三個(gè)是面試官用來挖坑的。為什么禁止指令重排很關(guān)鍵?最經(jīng)典的應(yīng)用就是DCL雙重檢查鎖單例模式,instance new Singleton()這行代碼在字節(jié)碼層面可以拆成“分配內(nèi)存-初始化對象-將引用賦值給變量”三個(gè)步驟,如果不加volatile,JVM指令重排后可能出現(xiàn)“先賦值引用、后初始化對象”的情況,另一個(gè)線程此時(shí)拿到引用,卻讀到未初始化的半成品對象。CAS(Compare And Swap)的原理要往底層說:它依賴CPU的cmpxchg指令,JDK里通過Unsafe類封裝成本地方法調(diào)用,AtomicInteger等原子類就是靠它實(shí)現(xiàn)的。CAS最大的坑是ABA問題:值從A變成B又變回A,再來一個(gè)線程執(zhí)行CAS時(shí)發(fā)現(xiàn)值還是A,就誤以為“沒人動過”。解決辦法是加版本號或時(shí)間戳,JDK自帶的AtomicStampedReference就是干這個(gè)的。面試官還喜歡問:JUC里為什么還要有LongAdder,它在高并發(fā)下為什么比AtomicInteger快?因?yàn)長ongAdder把單一value拆成了一個(gè)base加一個(gè)Cell數(shù)組,多個(gè)線程分散到不同Cell上各自累加,最后sum時(shí)再把所有值加起來,這樣顯著減少了CAS沖突。能把這個(gè)演進(jìn)邏輯講清楚,說明你真的理解并發(fā)包的設(shè)計(jì)思想,而不只是背類名。ThreadLocal這個(gè)考點(diǎn)要答出三個(gè)層次:用法(每個(gè)線程一份獨(dú)立變量副本)、原理(每個(gè)Thread內(nèi)部有ThreadLocalMap,key是ThreadLocal的弱引用,value是強(qiáng)引用)、內(nèi)存泄漏(為什么弱引用key還會泄漏——因?yàn)関alue是強(qiáng)引用鏈,線程池里的線程長期存活,value就一直沒有被回收)。對應(yīng)解決辦法也有兩個(gè):一是每次用完主動remove(),二是用static修飾ThreadLocal變量,延長它的生命周期,避免頻繁創(chuàng)建導(dǎo)致map里堆積過多無效entry。熱詞里還有個(gè)“java定時(shí)任務(wù)框架”,這個(gè)也常和并發(fā)串在一起考:Scheduled注解的底層是ScheduledThreadPoolExecutor,基于DelayQueue實(shí)現(xiàn)到期任務(wù)的調(diào)度,而不是簡單地開一個(gè)死循環(huán),能把這個(gè)底層說清楚,面試官就知道你不是只會用注解。3.3 線程池參數(shù):核心線程數(shù)到底怎么定線程池的七個(gè)參數(shù)(corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler)背出來不難,難的是“核心線程數(shù)到底怎么定”。網(wǎng)上流傳著“CPU密集型設(shè)N1、IO密集型設(shè)2N”的經(jīng)驗(yàn)法則,但說實(shí)話,這個(gè)法則能讓你過及格線,不能讓你拿高分。更好的回答方式是分層遞進(jìn)。如果是CPU密集型任務(wù),核心線程數(shù)設(shè)為CPU核心數(shù)加1;如果是IO密集型任務(wù),線程數(shù)可以設(shè)大一些,因?yàn)榫€程大部分時(shí)間在等待IO;但更科學(xué)的做法是基于Brian Goetz提出的估算公式:線程數(shù) CPU核心數(shù) * (1 等待時(shí)間 / 計(jì)算時(shí)間)。先估算每個(gè)任務(wù)里等待和計(jì)算的比例,再帶入公式,得到一個(gè)初始參考值,最后通過壓測驗(yàn)證和調(diào)整。這個(gè)公式能回答“網(wǎng)上說2N到底怎么來的”——如果等待時(shí)間和計(jì)算時(shí)間相等,公式結(jié)果就是2倍的CPU核心數(shù)。能說到這層,面試官基本就會覺得你做過有深度的性能設(shè)計(jì),而不是只會抄公式。拒絕策略也是?？键c(diǎn),四種策略要分清:AbortPolicy是默認(rèn)策略,直接拋異常;CallerRunsPolicy用調(diào)用者線程執(zhí)行任務(wù),適合不想丟任務(wù)的場景,但會導(dǎo)致調(diào)用線程阻塞;DiscardPolicy靜默丟棄;DiscardOldestPolicy丟棄隊(duì)列里最老的任務(wù)。實(shí)際項(xiàng)目里我比較推薦CallerRunsPolicy,尤其在Web應(yīng)用里,能起到輕量背壓的作用;同時(shí)要提醒一句,如果使用CallerRunsPolicy,你的調(diào)用線程可能被阻塞在任務(wù)里,主流程的響應(yīng)時(shí)間可能會被拉長,需要提前評估好隊(duì)列容量和最大線程數(shù)。4. Spring家族與Spring Boot:框架題背后的設(shè)計(jì)思想4.1 Spring Bean生命周期與循環(huán)依賴Bean生命周期這道題,建議答出完整過程:實(shí)例化 - 屬性填充 - Aware回調(diào)(BeanNameAware、BeanFactoryAware、BeanClassLoaderAware) - BeanPostProcessor的postProcessBeforeInitialization - InitializingBean的afterPropertiesSet - 自定義init-method - BeanPostProcessor的postProcessAfterInitialization - Bean正常使用 - 銷毀階段(DestructionAwareBeanPostProcessor、DisposableBean、自定義destroy-method)。面試官考這條鏈路,不只是考記憶,更是看你能不能理解Spring AOP代理為什么恰好發(fā)生在postProcessAfterInitialization階段——因?yàn)榇韺ο蟮膭?chuàng)建和包裝就出現(xiàn)在這個(gè)位置。如果你還能說出“PostConstruct注解方法是在postProcessBeforeInitialization之后執(zhí)行的,它的底層是CommonAnnotationBeanPostProcessor”,那就更扎實(shí)了。循環(huán)依賴是真正的區(qū)分度題目。核心要答出:Spring通過三級緩存解決單例Bean的循環(huán)依賴。一級緩存singletonObjects存放成品對象,二級緩存earlySingletonObjects存放早期暴露的半成品對象,三級緩存singletonFactories存放ObjectFactory工廠。流程是:A創(chuàng)建時(shí)發(fā)現(xiàn)需要B,先把A的ObjectFactory暴露到三級緩存,然后去創(chuàng)建B;B創(chuàng)建時(shí)發(fā)現(xiàn)需要A,從三級緩存拿到A的工廠,把A提前放入二級緩存并完成注入;B創(chuàng)建完成后,再回到A,把A的其余屬性補(bǔ)齊。這里有個(gè)必須想明白的點(diǎn):為什么一定要三級緩存,二級行不行?因?yàn)槿壘彺娲娴氖荗bjectFactory,在需要動態(tài)代理時(shí),可以在這里通過getEarlyBeanReference提前包裝出代理對象,保證提前暴露的對象和最終注入的對象是同一個(gè)。但如果你答到這里,面試官很可能會追加一句:為什么Autowired字段注入能解決循環(huán)依賴,構(gòu)造器注入?yún)s不行?因?yàn)闃?gòu)造器注入在實(shí)例化階段就要傳入依賴,此時(shí)對象本身還沒創(chuàng)建出來,三級緩存還沒機(jī)會暴露它,所以無解。另外,prototype作用域的Bean以及Async注解的Bean默認(rèn)也不支持循環(huán)依賴,這兩個(gè)細(xì)節(jié)很容易被忽略,記一下。4.2 Spring Boot自動配置原理自動配置是Spring Boot的招牌考點(diǎn),答題主線非常清晰:SpringBootApplication是SpringBootConfiguration、EnableAutoConfiguration、ComponentScan三個(gè)注解的組合。EnableAutoConfiguration通過Import(AutoConfigurationImportSelector.class)導(dǎo)入一批自動配置類,AutoConfigurationImportSelector會讀取類路徑下的META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件(Spring Boot 2.7之后的位置,老版本是spring.factories),把所有候選自動配置類列出來,再根據(jù)ConditionalOnXxx這一組條件注解逐個(gè)判斷是否生效。比如ConditionalOnClass判斷classpath下有沒有對應(yīng)的依賴類,ConditionalOnProperty判斷配置項(xiàng)有沒有開啟。這就是為什么你引入Redis依賴后Spring Boot能自動裝配RedisTemplate,移除依賴后所有相關(guān)配置自動失效。熱詞里還有springboot面試題和spring面試題,如果時(shí)間只夠準(zhǔn)備兩道Spring題,我建議準(zhǔn)備這道自動配置原理,再加一道AOP題。AOP的考點(diǎn)是動態(tài)代理的兩種方式:JDK動態(tài)代理要求目標(biāo)類實(shí)現(xiàn)接口,基于反射的Proxy和InvocationHandler;CGLIB代理則通過繼承目標(biāo)類、用ASM字節(jié)碼生成子類來實(shí)現(xiàn)。Spring Boot 2.x之后默認(rèn)使用CGLIB,proxyTargetClasstrue,所以即使目標(biāo)類沒有接口也能代理。同時(shí)要能說出Transactional的失效場景,這道題出現(xiàn)率極高:方法不是public、同類內(nèi)部自調(diào)用不走代理、異常被catch吞掉、檢查型異常默認(rèn)不觸發(fā)回滾、類沒有被Spring容器管理。這五個(gè)場景,至少要說出來三個(gè),并且最好配合一個(gè)自己遇到過的小例子。4.3 MyBatis與ORM:面試?yán)锶菀缀雎缘募?xì)節(jié)MyBatis的面試題集中在幾個(gè)點(diǎn):#{}和${}的區(qū)別、一級緩存和二級緩存、Mapper接口的原理。#{}走預(yù)編譯參數(shù)綁定,能防止SQL注入;${}是字符串直接拼接,存在注入風(fēng)險(xiǎn),但也能用來動態(tài)指定表名、列名和排序字段。一級緩存是SqlSession級別的,默認(rèn)開啟,同一個(gè)SqlSession內(nèi)重復(fù)查詢相同語句會命中緩存;二級緩存是namespace級別的,需要手動開啟。Mapper接口能直接使用,是因?yàn)镾pring通過MapperProxy的JDK動態(tài)代理,把接口方法映射到了XML或注解里的SQL執(zhí)行邏輯。這里有個(gè)容易翻車的點(diǎn),很多人說${}完全不能用,這其實(shí)不嚴(yán)謹(jǐn)。${}確實(shí)有SQL注入風(fēng)險(xiǎn),所以業(yè)務(wù)參數(shù)一律要用#{};但如果你需要動態(tài)傳表名、ORDER BY的字段名,或者拼接固定的SQL片段,比如數(shù)據(jù)權(quán)限里的組織機(jī)構(gòu)ID列表,那就必須用${}。關(guān)鍵不在于“用不用”,而在于“拼進(jìn)去的內(nèi)容是否受控”,比如表名經(jīng)過白名單校驗(yàn)、排序字段通過枚舉映射,而不是直接拿用戶輸入去拼。能把這個(gè)細(xì)節(jié)答出來,面試官基本就認(rèn)可你寫過真實(shí)的生產(chǎn)代碼,而不是只在教程項(xiàng)目里跑過demo。5. 數(shù)據(jù)庫與緩存:MySQL、Redis是分水嶺5.1 MySQL索引、事務(wù)、鎖的必問題MySQL在Java面試?yán)锏牡匚灰呀?jīng)不亞于Java本身。索引這塊,必問B樹為什么適合做數(shù)據(jù)庫索引,分析時(shí)要把B樹、紅黑樹、哈希表三個(gè)對比對象拉出來:二叉樹深度太大導(dǎo)致磁盤IO次數(shù)太多,哈希索引不支持范圍查詢,而B樹的葉子節(jié)點(diǎn)存數(shù)據(jù)且形成有序鏈表,樹的高度低、范圍掃描能力強(qiáng),這就是InnoDB選擇B樹的核心原因。還要能講清楚聚簇索引和二級索引的區(qū)別:InnoDB的表數(shù)據(jù)本身就是按主鍵索引的B樹組織的,二級索引的葉子節(jié)點(diǎn)存的是主鍵值,所以使用二級索引查詢時(shí),如果需要的列不在索引里,就要再用主鍵回到聚簇索引上查一次,這個(gè)動作就叫“回表”。事務(wù)這塊,ACID四個(gè)特性打底,然后重點(diǎn)講隔離級別:讀未提交、讀已提交、可重復(fù)讀、串行化。InnoDB默認(rèn)是可重復(fù)讀,通過MVCC實(shí)現(xiàn)快照讀,通過next-key lock(記錄鎖加間隙鎖的組合)解決幻讀問題。這里有個(gè)值得背的細(xì)節(jié):MVCC依賴隱藏字段DB_TRX_ID和DB_ROLL_PTR,配合undo log實(shí)現(xiàn)多版本鏈,ReadView會在讀的時(shí)候判斷當(dāng)前事務(wù)能看到哪個(gè)版本的數(shù)據(jù)。能把這個(gè)鏈路講完整,已經(jīng)是中高級水平了。鎖的考點(diǎn)和熱詞里的分布式鎖面試題要區(qū)分開。MySQL層面的行鎖、表鎖、間隙鎖、死鎖排查屬于數(shù)據(jù)庫鎖,跨進(jìn)程協(xié)調(diào)資源的才叫分布式鎖。MySQL死鎖排查是高頻場景題,要會說:show engine innodb status查看最近一次死鎖信息,information_schema.innodb_trx查當(dāng)前事務(wù),information_schema.innodb_lock_waits查鎖等待關(guān)系,配合pt-deadlock-logger這類工具做長期監(jiān)測。如果面試官追問“死鎖怎么避免”,可以從業(yè)務(wù)層面加鎖順序一致化、縮短事務(wù)時(shí)間、合理設(shè)計(jì)索引減少鎖范圍幾個(gè)角度回答。5.2 Redis緩存穿透、擊穿、雪崩與分布式鎖Redis相關(guān)題,熱詞里能同時(shí)搜到redis面試題和分布式鎖面試題,可見這兩個(gè)方向火到什么程度。緩存三大問題是必考中的必考,而且很多人會在“穿透”和“擊穿”上翻車,我這里先把定義理清楚:穿透是查詢一個(gè)不存在的key,導(dǎo)致請求直接打到數(shù)據(jù)庫;擊穿是某個(gè)熱點(diǎn)key在失效的一瞬間,大量請求同時(shí)打到數(shù)據(jù)庫;雪崩是大量key同時(shí)失效,或者Redis實(shí)例整體不可用,導(dǎo)致數(shù)據(jù)庫被壓垮。解決方案分別是:穿透用布隆過濾器或緩存空值,擊穿用互斥鎖或邏輯過期方案,雪崩的基礎(chǔ)做法是給過期時(shí)間加隨機(jī)值,更進(jìn)一步的思路是熱點(diǎn)數(shù)據(jù)永不過期加后臺異步更新,或者搭建多級緩存。分布式鎖的完整回答鏈應(yīng)該分三步。先說明為什么需要分布式鎖:本地鎖synchronized在多實(shí)例部署下各自獨(dú)立,鎖不住跨進(jìn)程的共享資源。再講三種實(shí)現(xiàn)方案,并給出對比。方案一是Redis SETNX,核心命令是SET lockKey requestId NX PX 30000,注意兩個(gè)關(guān)鍵點(diǎn):value必須是請求唯一標(biāo)識,防止一個(gè)線程誤刪另一個(gè)線程的鎖;必須設(shè)置過期時(shí)間,防止持有鎖的線程宕機(jī)導(dǎo)致死鎖。釋放鎖時(shí)不能直接DEL,要先判斷value是不是自己,再用Lua腳本保證“比較刪除”的原子性。方案二是Redisson,通過看門狗機(jī)制對鎖自動續(xù)期,解決業(yè)務(wù)執(zhí)行時(shí)間超過鎖過期時(shí)間的問題,但要注意主從切換時(shí)鎖可能短暫丟失。方案三是ZooKeeper,基于臨時(shí)順序節(jié)點(diǎn)加監(jiān)聽機(jī)制,能提供嚴(yán)格意義上的強(qiáng)一致性,性能卻不如Redis。如果要說一個(gè)“有深度”的結(jié)尾,就提一句:Redis主從架構(gòu)下的鎖存在丟失風(fēng)險(xiǎn),對強(qiáng)一致要求高的場景可以考慮RedLock方案或者直接用ZooKeeper,沒有銀彈,按業(yè)務(wù)場景取舍。5.3 緩存一致性:哪些方案真的能用緩存一致性問題比三大緩存問題更有深度,也是現(xiàn)在的面試官非常喜歡在項(xiàng)目場景里追著問的話題。核心矛盾就一句話:數(shù)據(jù)庫更新了,怎么保證緩存里的舊數(shù)據(jù)不被讀到?最常見的方案是Cache Aside(旁路緩存):讀的時(shí)候先讀緩存,沒命中就查數(shù)據(jù)庫再回填;寫的時(shí)候先更新數(shù)據(jù)庫,然后刪除緩存。為什么是“刪緩存”而不是“更新緩存”?因?yàn)椴l(fā)環(huán)境下,多個(gè)線程同時(shí)更新緩存,很容易把舊值覆蓋成新值再被另一個(gè)舊值覆蓋,形成臟數(shù)據(jù);而刪除緩存配合懶加載,下次讀取時(shí)從數(shù)據(jù)庫重建,更安全。但刪緩存也有問題:刪完后、重建前的窗口期,如果有一個(gè)并發(fā)請求讀到了舊數(shù)據(jù)并回填緩存,就會導(dǎo)致臟讀。針對這個(gè)窗口,業(yè)界慣用的招數(shù)是延遲雙刪(刪除緩存 - 更新數(shù)據(jù)庫 - 休眠一小段時(shí)間 - 再刪一次),或者通過訂閱binlog的方式(Canal)異步刪除緩存。Write Through和Write Behind(異步寫回)也有各自的適用場景,但Write Behind要接受數(shù)據(jù)可能丟失的風(fēng)險(xiǎn),生產(chǎn)環(huán)境一般還是Cache Aside為主?；卮鸬氖瘴沧詈檬?沒有銀彈,要根據(jù)業(yè)務(wù)對一致性的容忍度和并發(fā)壓力做取舍,能說出這句話,面試官就覺得你是有實(shí)戰(zhàn)判斷力的。6. 分布式與消息隊(duì)列:從八股走向場景6.1 Kafka怎么答才有深度kafka面試題在熱詞里的搜索量一直很高。Kafka的基礎(chǔ)題包括:分區(qū)與副本機(jī)制、生產(chǎn)者消息發(fā)送流程、消費(fèi)者組與分區(qū)分配、offset提交機(jī)制、ISR機(jī)制、消息不丟失/不重復(fù)/不順序三個(gè)“不”。但按我的面試經(jīng)驗(yàn),現(xiàn)在的面試官更愿意把Kafka放進(jìn)具體場景里問,而不是單純抽概念。一個(gè)高頻場景題是這樣:訂單系統(tǒng)的消費(fèi)者在處理消息時(shí),業(yè)務(wù)邏輯拋異常了,這條消息怎么辦?正確思路是先判斷異常類型。如果是可重試的,比如依賴的下游服務(wù)短暫不可用,就用重試策略配合重試Topic,在Spring Kafka里對應(yīng)DefaultErrorHandler的retry配置,設(shè)置重試次數(shù)和間隔,超過重試次數(shù)后進(jìn)入死信隊(duì)列;如果是不可重試的,比如消息本身格式錯(cuò)誤,直接記錄完整日志、送入死信隊(duì)列,再通過定時(shí)任務(wù)或人工補(bǔ)償處理。千萬不能說“catch異常打日志就完事了”,那樣消費(fèi)位置已經(jīng)提交,消息就永遠(yuǎn)丟了。回答里如果能提到“消費(fèi)位置提交是Kafka不丟消息的關(guān)鍵一環(huán),要區(qū)分自動提交和手動提交”,那就更完整了。另一個(gè)?？碱}是Kafka為什么快。要答出四個(gè)核心原因:順序?qū)懘疟P(現(xiàn)代機(jī)器上磁盤順序IO的速度可以接近內(nèi)存隨機(jī)讀寫,這是Kafka高性能的基礎(chǔ))、頁緩存(消息先寫入操作系統(tǒng)的Page Cache而不是JVM堆,減少GC壓力)、零拷貝(利用sendfile和mmap減少用戶態(tài)與內(nèi)核態(tài)之間的數(shù)據(jù)拷貝次數(shù))、批量處理(生產(chǎn)者批量發(fā)送、消費(fèi)者批量拉取、broker批量存儲)。這四個(gè)點(diǎn)覆蓋了寫入、緩存、網(wǎng)絡(luò)傳輸和IO四個(gè)維度,能把每個(gè)點(diǎn)展開說一兩句,就已經(jīng)比絕大多數(shù)候選人強(qiáng)了。6.2 分布式事務(wù):2PC、TCC還是最終一致性分布式事務(wù)是Java高級崗的必問題,不管熱詞里搜的是springboot面試題還是kafka面試題,都容易牽扯到這里。基礎(chǔ)的三板斧要能說清楚:2PC兩階段提交,協(xié)調(diào)者先詢問所有參與者能否prepare,全部成功后再統(tǒng)一commit,缺點(diǎn)是同步阻塞、協(xié)調(diào)者單點(diǎn)、第二階段可能出現(xiàn)不一致;TCC(Try-Confirm-Cancel)把業(yè)務(wù)拆成三個(gè)階段,業(yè)務(wù)侵入比較大,每個(gè)操作都要寫三套邏輯,適合對一致性要求高的場景;本地消息表加MQ最終一致性最務(wù)實(shí),核心思路是把“寫業(yè)務(wù)數(shù)據(jù)”和“寫消息表”放在同一個(gè)本地事務(wù)里,然后通過定時(shí)任務(wù)掃描未發(fā)送的消息,把消息可靠地投遞到MQ,下游消費(fèi)成功后回調(diào)確認(rèn)。站在當(dāng)下這個(gè)時(shí)間點(diǎn)的面試角度,我更推薦你額外準(zhǔn)備一下Seata的AT模式,因?yàn)樗鼛缀跏乾F(xiàn)在企業(yè)落地的標(biāo)準(zhǔn)答案。AT模式通過全局事務(wù)ID加分支事務(wù),配合undo_log里記錄的before鏡像和after鏡像,自動生成反向SQL來補(bǔ)償,對業(yè)務(wù)代碼改動非常小,是一種無侵入的最終一致性方案。答題順序可以是:先把2PC、TCC、消息最終一致性講一遍,然后結(jié)合自己的項(xiàng)目說“為什么我選了最終一致性而不是強(qiáng)一致”,比如訂單創(chuàng)建后扣庫存、加積分這類場景,用戶能容忍幾秒鐘的延遲,但對系統(tǒng)吞吐量有明確要求,用最終一致性是合理的取舍。能說出“取舍”二字,面試官才會覺得你有架構(gòu)思維,而不是背了一堆名詞。7. 算法與手寫題:冒泡排序都能暴露問題7.1 高頻手寫代碼題清單熱詞里冒泡排序java赫然在列,這算是熱度最高的單一算法詞了。別覺得“這么簡單不可能考”,我當(dāng)面試官的時(shí)候,真的見過很多人在白板上寫冒泡排序?qū)懗鏊姥h(huán)或者邊界錯(cuò)誤。冒泡排序的標(biāo)準(zhǔn)寫法是:public static void bubbleSort(int[] arr) { if (arr null || arr.length 2) { return; } for (int i 0; i arr.length - 1; i) { boolean swapped false; for (int j 0; j arr.length - 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) { // 這一輪沒有發(fā)生交換,說明數(shù)組已經(jīng)有序,提前結(jié)束 break; } } }這個(gè)版本加了swapped標(biāo)記,是優(yōu)化過的冒泡排序,最好情況下時(shí)間復(fù)雜度可以到O(n)。面試官考排序不只是看你會不會寫,還會讓你分析時(shí)間復(fù)雜度和穩(wěn)定性:冒泡穩(wěn)定、快排不穩(wěn)定、歸并穩(wěn)定,這些要能夠脫口而出。最好