復(fù)習(xí)筆記：集合、并發(fā)、JVM與動(dòng)態(tài)代理面試要點(diǎn))
本來這個(gè)系列的更新節(jié)奏被我拖了很久。前兩篇把Java基礎(chǔ)語法、面向?qū)ο蠛统Ｓ肁PI過了一遍這次趁著項(xiàng)目告一段落把集合框架、函數(shù)式編程、并發(fā)編程、JVM內(nèi)存模型以及反射動(dòng)態(tài)代理這五塊硬骨頭又快速擼了一遍。說實(shí)話每次復(fù)習(xí)都能發(fā)現(xiàn)幾個(gè)之前“以為自己知道其實(shí)沒吃透”的點(diǎn)尤其是HashMap底層和線程池參數(shù)真到了面試或者排查線上問題的時(shí)候才知道基礎(chǔ)扎實(shí)有多重要。這篇就當(dāng)我的復(fù)習(xí)筆記加面試前自檢清單如果你也在準(zhǔn)備Java面試或者想系統(tǒng)性地鞏固一遍核心基礎(chǔ)建議跟著過一遍遇到不熟的地方再往深挖。1. 先把“地基”踩實(shí)從環(huán)境變量到編譯運(yùn)行1.1 環(huán)境變量到底在配什么很多初學(xué)者在環(huán)境變量這一步就卡住了網(wǎng)上教程一大堆照著配完仍然java -version報(bào)錯(cuò)。其實(shí)環(huán)境變量的核心就三個(gè)JAVA_HOME、PATH、CLASSPATH。JAVA_HOME告訴系統(tǒng)和各種構(gòu)建工具JDK 到底裝在哪里。后續(xù) Maven、Tomcat、IDEA 找 JDK都是優(yōu)先讀這個(gè)變量。PATH讓命令行能在任意目錄直接執(zhí)行java、javac原理就是把%JAVA_HOME%\bin這個(gè)目錄塞進(jìn)系統(tǒng)搜索路徑。CLASSPATH指定類加載器去哪兒找第三方類庫。JDK 1.5 之后不配 CLASSPATH 也能編譯運(yùn)行基本程序因?yàn)榫幾g器默認(rèn)會(huì)找當(dāng)前目錄所以新手階段不用被它嚇住。配置時(shí)最容易被忽視的一個(gè)細(xì)節(jié)是改完環(huán)境變量后已經(jīng)打開的命令行窗口不會(huì)自動(dòng)生效必須重新開一個(gè)窗口。另一個(gè)高頻坑是多個(gè) JDK 版本殘留PATH里前面的 JDK 8 把后面的 JDK 17 擋住了導(dǎo)致java -version顯示的版本和JAVA_HOME對不上。排查方法很簡單在命令行執(zhí)行where java把實(shí)際命中的路徑找出來然后去PATH里調(diào)整順序。1.2 從 NoClassDefFoundError 聊到類路徑問題熱詞里有個(gè)非常典型的報(bào)錯(cuò)uncaught exception java.lang.noclassdeffounderror: java/applet/applet in thr?？吹絅oClassDefFoundError很多人的第一反應(yīng)是“類找不到”但嚴(yán)格來說它和ClassNotFoundException是兩回事。ClassNotFoundException運(yùn)行時(shí)通過Class.forName()或ClassLoader.loadClass()動(dòng)態(tài)加載類結(jié)果類路徑下壓根沒有這個(gè)類拋的是受檢異常是“主動(dòng)找類沒找到”。NoClassDefFoundError類在編譯期存在但運(yùn)行期類路徑變了或者某個(gè)靜態(tài)初始化塊拋了異常導(dǎo)致 JVM 無法完成這個(gè)類的定義。它是 Error不是 Exception說明 JVM 本身已經(jīng)處在不穩(wěn)定的狀態(tài)。出現(xiàn)java/applet/applet這種老掉牙的類找不到多半是項(xiàng)目里引用了某些老庫或者編譯目標(biāo)版本設(shè)置得太老運(yùn)行時(shí)卻用了高版本 JDK高版本 JDK 已經(jīng)移除了 Applet 相關(guān)模塊。解決辦法不是去網(wǎng)上隨便找個(gè) jar 塞進(jìn)去而是要檢查依賴樹看看誰傳遞依賴引入了這個(gè)老類再考慮排除或者升級(jí)依賴版本。順帶提一句Lombok 的you arent using a compiler supported by lombok報(bào)錯(cuò)也屬于“編譯期工具鏈不匹配”問題本質(zhì)是 JDK 版本和 Lombok 版本不兼容優(yōu)先升級(jí) Lombok 版本而不是去改編譯器參數(shù)。2. 集合框架不是背 API而是理解數(shù)據(jù)結(jié)構(gòu)2.1 集合整體結(jié)構(gòu)梳理Java 集合框架的核心接口就兩個(gè)方向Collection和Map。Collection下面分了List、Set、QueueMap則獨(dú)立一條線。理解這個(gè)體系不是為了面試時(shí)背出類名而是為了選型時(shí)腦子里有圖景。日常開發(fā)中最常用的選型大致可以按三條標(biāo)準(zhǔn)來判斷場景推薦實(shí)現(xiàn)原因需要有序、可重復(fù)、按下標(biāo)隨機(jī)訪問ArrayList底層數(shù)組隨機(jī)訪問 O(1)需要頻繁在中間插入/刪除、不關(guān)心隨機(jī)訪問LinkedList底層雙向鏈表增刪只改指針需要去重且不要求順序HashSet / LinkedHashSet基于 HashMap去重 O(1)需要按 key 快速查找 valueHashMap哈希表平均 O(1)并發(fā)環(huán)境下需要線程安全的 MapConcurrentHashMapCAS synchronized鎖粒度細(xì)2.2 ArrayList 擴(kuò)容與 LinkedList 的真相ArrayList 底層的擴(kuò)容機(jī)制是面試必問點(diǎn)。它默認(rèn)初始容量是 10每次擴(kuò)容變成原來的 1.5 倍oldCapacity (oldCapacity 1)。這里有個(gè)值得注意的細(xì)節(jié)如果一次性 addAll 添加大量元素按 1.5 倍逐步擴(kuò)會(huì)頻繁拷貝數(shù)組所以源碼里做了grow時(shí)判斷“實(shí)際需要的最小容量”來避免無意義的擴(kuò)容。LinkedList 的“增刪快”其實(shí)有很大前提。它確實(shí)在頭部和中間插入時(shí)不需要搬移元素但由于鏈表節(jié)點(diǎn)是分散在堆內(nèi)存的CPU 緩存命中率低再加上每次插入都要 new 一個(gè) Node 對象實(shí)際性能在絕大多數(shù)場景下反而不如 ArrayList。我做過一次簡單的基準(zhǔn)測試在 100 萬元素規(guī)模下中部插入 LinkedList 確實(shí)比 ArrayList 快但頭部插入因?yàn)?LinkedList 有頭指針勉強(qiáng)有優(yōu)勢尾部和隨機(jī)訪問則全面落后。結(jié)論很簡單能用 ArrayList 就用 ArrayListLinkedList 更多時(shí)候是退路而不是首選。2.3 HashMap 底層原理從數(shù)組鏈表到紅黑樹HashMap 是集合框架里邊最值得深挖的一個(gè)類。它的底層結(jié)構(gòu)在 JDK 1.8 之后是“數(shù)組 鏈表 紅黑樹”。put 一個(gè) key-value 時(shí)先對 key 的 hashCode 做一次擾動(dòng)運(yùn)算(h key.hashCode()) ^ (h 16)目的是讓高 16 位也參與尋址降低哈希沖突概率然后(n - 1) hash計(jì)算出數(shù)組下標(biāo)。鏈表什么時(shí)候轉(zhuǎn)紅黑樹這里有個(gè)容易記混的閾值鏈表長度超過 8并且數(shù)組長度大于等于 64才轉(zhuǎn)紅黑樹如果數(shù)組長度不足 64優(yōu)先擴(kuò)容而不是轉(zhuǎn)樹。為什么是 8因?yàn)樽髡咴谠创a注釋里說了遵循泊松分布在負(fù)載因子 0.75 的情況下鏈表長度達(dá)到 8 的概率已經(jīng)降到千萬分之六以下這時(shí)候轉(zhuǎn)紅黑樹是為了防止極端哈希沖突下查詢退化成 O(n)。理解這個(gè)概率之后就不會(huì)再死記硬背“鏈表長度大于 8 就轉(zhuǎn)樹”這種片面的說法了。負(fù)載因子 0.75 也是個(gè)很經(jīng)典的設(shè)計(jì)。它是時(shí)間成本減少擴(kuò)容次數(shù)和空間成本避免數(shù)組太稀疏的折中。JDK 1.7 里 HashMap 的頭插法在并發(fā)擴(kuò)容時(shí)會(huì)形成環(huán)形鏈表導(dǎo)致 get 死循環(huán)1.8 改成尾插法之后死循環(huán)問題解決了但 HashMap 在并發(fā)下仍然會(huì)丟數(shù)據(jù)所以并發(fā)場景永遠(yuǎn)不要用 HashMap直接用ConcurrentHashMap。2.4 ConcurrentHashMap并發(fā)場景下的正解ConcurrentHashMap在 JDK 1.7 里用的是分段鎖Segment 繼承 ReentrantLock1.8 之后廢棄了分段鎖改成了CAS synchronized鎖住數(shù)組的每個(gè)桶節(jié)點(diǎn)。put 時(shí)先 CAS 判斷當(dāng)前桶是否為空為空就直接 CAS 插入不為空才 synchronized 鎖住頭節(jié)點(diǎn)再走鏈表或者紅黑樹的插入邏輯。這個(gè)設(shè)計(jì)把鎖粒度從“一段區(qū)域”縮小到“單個(gè)桶”并發(fā)度提升非常明顯而且能兼容之前用 HashMap 的絕大多數(shù)代碼。有朋友經(jīng)常把ConcurrentHashMap和Hashtable搞混。Hashtable是給整個(gè)表加一把重量級(jí)鎖并發(fā)讀都要串行早就該淘汰了。還有Collections.synchronizedMap()它本質(zhì)是包裝類把所有方法都加上 synchronized鎖粒度同樣粗。所以面試?yán)锉粏柕健熬€程安全的 Map 有哪些”最優(yōu)答案就是ConcurrentHashMap并且要說清楚它為什么比另外兩個(gè)更優(yōu)秀。3. Lambda 與 Stream切換到函數(shù)式思維3.1 Lambda 語法速記Lambda 表達(dá)式的本質(zhì)是“函數(shù)式接口的匿名實(shí)現(xiàn)”。所謂函數(shù)式接口就是只包含一個(gè)抽象方法的接口比如Runnable、Comparator、Function。語法結(jié)構(gòu)可以拆成三部分參數(shù)列表、箭頭、函數(shù)體。// 無參Runnable Runnable task () - System.out.println(run); // 單參Consumer ConsumerString consumer s - System.out.println(s); // 多參Comparator ComparatorInteger comparator (a, b) - a - b;剛學(xué) Lambda 時(shí)最容易蒙的是“什么時(shí)候能省略參數(shù)類型”。答案是只要編譯器能從上下文推斷出類型就可以省略。比如stream.map(s - s.length())編譯器知道s是String就不需要寫(String s) -。但如果是自己定義泛型方法推斷不出來的時(shí)候就必須顯式寫類型。3.2 Stream 常用操作與實(shí)戰(zhàn)Stream 的核心思想是“流水線”數(shù)據(jù)源經(jīng)過一系列中間操作最后由終端操作觸發(fā)計(jì)算。中間操作只做聲明不會(huì)真的計(jì)算這就是“惰性求值”。最常用的幾個(gè)操作filter按條件過濾map一對一轉(zhuǎn)換flatMap把一個(gè)元素展開成多個(gè)元素sorted排序可以傳 Comparatordistinct去重collect把流收集成 List/Set/Mapreduce把整個(gè)流歸約為一個(gè)值代碼示例統(tǒng)計(jì)訂單列表中金額超過 100 的訂單總額ListOrder orderList ...; double total orderList.stream() .filter(o - o.getAmount() 100) .mapToDouble(Order::getAmount) .sum();這里面有個(gè)很實(shí)用的點(diǎn)處理基本數(shù)值流的時(shí)候優(yōu)先用IntStream、LongStream、DoubleStream尤其是 sum、max、min 這類聚合操作比自己reduce再拆箱裝箱省心很多。熱搜詞里提到的“Java 字符串多行寫法”其實(shí)也適合放在這里說。JDK 15 正式引入了文本塊配合 Stream 處理多行文本非常舒服String json { name: Java, age: 27 } ;文本塊不需要寫一堆\n拼接代碼可讀性提升明顯但要注意它保留縮進(jìn)的方式以及后面不能直接跟內(nèi)容。3.3 Lambda 與 Stream 的坑第一個(gè)坑流只能消費(fèi)一次。一個(gè)Stream對象調(diào)用過終端操作之后就被關(guān)閉了再調(diào)用會(huì)拋IllegalStateException: stream has already been operated upon or closed。解決辦法就是用的時(shí)候現(xiàn)場生成新流不要反復(fù)用同一個(gè)變量。第二個(gè)坑Lambda 捕獲的局部變量必須是 effectively final。也就是說變量沒被顯式聲明為 final但后續(xù)沒有被重新賦值才能被 Lambda 引用。如果你在 Lambda 內(nèi)部嘗試修改外部變量的值編譯直接報(bào)錯(cuò)。想累加計(jì)數(shù)怎么辦用AtomicInteger或者干脆改成流里的收集器。第三個(gè)坑并行流parallelStream()在共享可變狀態(tài)時(shí)會(huì)出大問題。比如在并行流里往同一個(gè) ArrayList 里 add 數(shù)據(jù)不僅線程不安全而且結(jié)果隨機(jī)。真要并行處理數(shù)據(jù)優(yōu)先用collect做歸約保證每段線程處理獨(dú)立的數(shù)據(jù)塊最后合并結(jié)果。4. 并發(fā)編程線程、鎖與線程池4.1 創(chuàng)建線程的三種方式及選擇創(chuàng)建線程傳統(tǒng)上有三種方式繼承Thread、實(shí)現(xiàn)Runnable、實(shí)現(xiàn)Callable。繼承Thread的問題在于 Java 是單繼承繼承了 Thread 就不能繼承別的類了擴(kuò)展性太差實(shí)現(xiàn)Runnable沒有返回值也拿不到執(zhí)行結(jié)果Callable配合FutureTask可以拿到返回值并且能拋異常。ExecutorService executor Executors.newFixedThreadPool(4); FutureInteger future executor.submit(() - { Thread.sleep(2000); return 1 1; }); Integer result future.get(); // 這里會(huì)阻塞等待任務(wù)完成熱搜詞“java線程等待都完成”對應(yīng)的就是這種場景。除了Future.get()逐個(gè)等待更優(yōu)雅的是用CountDownLatch或者CompletableFuture.allOf()。CountDownLatch 適合“等 N 個(gè)線程都做完再繼續(xù)主線程”的場景比如批量導(dǎo)出報(bào)表等所有分片查詢線程結(jié)束后統(tǒng)一生成 ZIP 文件。4.2 synchronized 與 JUC 鎖到底怎么選synchronized從 JDK 1.6 開始經(jīng)歷了鎖升級(jí)過程無鎖 - 偏向鎖 - 輕量級(jí)鎖 - 重量級(jí)鎖。鎖只能升級(jí)不能降級(jí)這是為了在不同競爭程度下尋找性能平衡。重量級(jí)鎖依賴操作系統(tǒng)的互斥量線程掛起喚醒涉及內(nèi)核態(tài)切換成本很高所以 JVM 才費(fèi)盡心思設(shè)計(jì)偏向鎖和輕量級(jí)鎖來減少這種切換。JUC包下的ReentrantLock則更靈活支持公平鎖、非公平鎖支持tryLock()超時(shí)控制支持多個(gè) Condition 條件變量。但偏偏這兩個(gè)鎖的選擇很多面試者說反了。簡單地說JDK 1.6 之后 synchronized 性能已經(jīng)和 ReentrantLock 差距不大能用 synchronized 就優(yōu)先用 synchronized因?yàn)樗?JVM 原生支持的使用簡單、不會(huì)因?yàn)橥浗怄i導(dǎo)致死鎖。需要公平鎖、超時(shí)中斷、多條件隊(duì)列這種高級(jí)特性時(shí)才考慮ReentrantLock。4.3 線程池參數(shù)面試?？忌a(chǎn)常踩坑ThreadPoolExecutor有七個(gè)核心參數(shù)corePoolSize核心線程數(shù)maximumPoolSize最大線程數(shù)keepAliveTime非核心線程的空閑存活時(shí)間unit時(shí)間單位workQueue任務(wù)隊(duì)列threadFactory線程工廠handler拒絕策略執(zhí)行流程一句話概括先讓核心線程跑核心線程滿了就進(jìn)隊(duì)列隊(duì)列滿了才創(chuàng)建非核心線程到最大線程數(shù)再滿就觸發(fā)拒絕策略。這個(gè)順序非常關(guān)鍵面試經(jīng)常搞混的是“隊(duì)列和最大線程數(shù)的先后關(guān)系”——很多人誤以為核心線程滿后直接創(chuàng)建新線程其實(shí)中間還隔著一個(gè)隊(duì)列。生產(chǎn)環(huán)境大忌就是用Executors.newFixedThreadPool()和newCachedThreadPool()。前者隊(duì)列是無界的LinkedBlockingQueue當(dāng)任務(wù)激增時(shí)隊(duì)列無限堆積內(nèi)存直接飆升后者最大線程數(shù)是Integer.MAX_VALUE任務(wù)一多線程瘋狂創(chuàng)建開銷極大。正確做法是用ThreadPoolExecutor的構(gòu)造函數(shù)顯式指定有界隊(duì)列和自定義拒絕策略。拒絕策略的四種實(shí)現(xiàn)也要掌握策略行為AbortPolicy直接拋 RejectedExecutionException默認(rèn)策略CallerRunsPolicy不用線程池由提交任務(wù)的線程自己執(zhí)行DiscardPolicy靜默丟棄任務(wù)DiscardOldestPolicy丟棄隊(duì)列中最早的任務(wù)再重試提交我個(gè)人偏愛CallerRunsPolicy因?yàn)樵诹髁扛叻鍟r(shí)它會(huì)把壓力傳回調(diào)用方起到天然背壓的效果不會(huì)靜默丟消息。5. JVM 內(nèi)存與異常從 StackOverflow 到 OOM 的排查思路5.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)快速瀏覽JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)可以按“線程共享”和“線程私有”來分線程私有虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器線程共享堆、方法區(qū)JDK 8 之后是元空間 Metaspace、運(yùn)行時(shí)常量池虛擬機(jī)棧里每個(gè)方法對應(yīng)一個(gè)棧幀棧幀里有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口。方法調(diào)用層級(jí)太深比如遞歸沒有出口就會(huì)拋StackOverflowError。堆里放對象實(shí)例絕大多數(shù) OOM 都發(fā)生在這里。程序計(jì)數(shù)器是唯一不會(huì) OOM 的區(qū)域因?yàn)樗淖饔弥皇怯涗洰?dāng)前線程執(zhí)行到哪一條字節(jié)碼指令空間幾乎可以忽略。5.2 高頻 OOM 類型與排查思路熱詞里有一個(gè)java: outofmemoryerror: insufficient memory這是比較典型的“內(nèi)存不足”提示。但在真實(shí) JVM 里OOM 還要細(xì)分成幾種類型原因排查方向Java heap space堆內(nèi)存不足對象太多或內(nèi)存泄漏抓 heap dump用 MAT 找大對象、查引用鏈GC overhead limit exceededGC 時(shí)間過長但回收效果極差優(yōu)先檢查堆大小配置再查泄漏Metaspace類元數(shù)據(jù)過多常由動(dòng)態(tài)生成類導(dǎo)致查 CGLIB/反射動(dòng)態(tài)代理生成類是否過量unable to create new native thread操作系統(tǒng)線程數(shù)達(dá)到上限ulimit、線程池參數(shù)、減少線程數(shù)排查堆內(nèi)存 OOM第一步不是改-Xmx而是抓現(xiàn)場?？梢约?JVM 參數(shù)-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump讓 JVM 在 OOM 時(shí)自動(dòng)導(dǎo)出堆轉(zhuǎn)儲(chǔ)文件。然后用jstat -gcutil pid看 GC 情況用jmap -histo pid看對象分布再用 MAT 分析 dump 文件的支配樹基本能定位到泄漏源。這里有個(gè)容易被忽略的經(jīng)驗(yàn)很多號(hào)稱“內(nèi)存泄漏”的問題其實(shí)是ThreadLocal沒清理或者是static集合一直持有對象引用。特別是ThreadLocal在線程池場景下如果線程不復(fù)用還好一旦線程長期存活且沒有調(diào)用remove()ThreadLocalMap 里的 Entry 會(huì)一直被線程持有形成內(nèi)存泄漏。5.3 異常體系與 try-with-resourcesJava 異常分兩大類Error和Exception。Error是 JVM 層面的嚴(yán)重問題比如StackOverflowError、OutOfMemoryError應(yīng)用程序通常不應(yīng)該去捕獲。Exception又分受檢異常IOException、SQLException和非受檢異常NullPointerException、IllegalArgumentException。受檢異常強(qiáng)制處理非受檢異常不強(qiáng)制。這個(gè)設(shè)計(jì)本意是好的但實(shí)際項(xiàng)目里經(jīng)常被濫用。我的習(xí)慣是外部環(huán)境導(dǎo)致的、可恢復(fù)的異常用受檢異常程序 bug 導(dǎo)致的、修代碼才能解決的問題用 RuntimeException。處理 IO 流時(shí)JDK 7 之后一定要用try-with-resources寫法自動(dòng)關(guān)閉資源。它有兩個(gè)好處第一不用在 finally 里寫一堆 null 判斷第二當(dāng)主體的異常和 close 的異常同時(shí)發(fā)生時(shí)close 的異常會(huì)被壓制suppressed主體異常優(yōu)先拋出。try (BufferedReader reader Files.newBufferedReader(path)) { String line reader.readLine(); } catch (IOException e) { log.error(read failed, e); }6. 反射與動(dòng)態(tài)代理框架底層的秘密6.1 反射核心 API反射是框架設(shè)計(jì)的基石Spring 的依賴注入、MyBatis 的 mapper 映射、Retrofit 的動(dòng)態(tài)接口實(shí)現(xiàn)底層全是反射和動(dòng)態(tài)代理。反射的入口是Class對象有三種獲取方式類名.class、對象.getClass()、Class.forName(全限定類名)。拿到Class之后可以獲取構(gòu)造器、方法、字段并繞過訪問控制去調(diào)用或修改。Class? clazz Class.forName(com.example.User); Constructor? constructor clazz.getDeclaredConstructor(String.class); constructor.setAccessible(true); // 繞過 private 構(gòu)造器檢查 Object user constructor.newInstance(張三);反射的性能天然比直接調(diào)用慢因?yàn)樗馕鲱愋汀z查訪問權(quán)限、走 JNI 后續(xù)的一系列動(dòng)態(tài)邏輯。不過現(xiàn)代 JVM 有針對反射的緩存優(yōu)化平時(shí)業(yè)務(wù)代碼里不需要過度擔(dān)心那點(diǎn)性能差但如果在一個(gè)高頻調(diào)用鏈路上反復(fù)用反射就該考慮在啟動(dòng)階段緩存Method對象而不是每次調(diào)用都getMethod()重新查找。6.2 JDK 動(dòng)態(tài)代理與 CGLIB 的區(qū)別動(dòng)態(tài)代理的面試考點(diǎn)集中在這兩種實(shí)現(xiàn)方式的原理和區(qū)別上。JDK 動(dòng)態(tài)代理基于接口。代理類在運(yùn)行時(shí)通過Proxy.newProxyInstance()生成要求目標(biāo)類必須實(shí)現(xiàn)接口。它本質(zhì)是構(gòu)造了一個(gè)實(shí)現(xiàn)了同樣接口的代理對象然后在InvocationHandler.invoke()方法里做增強(qiáng)邏輯。CGLIB基于繼承。通過生成目標(biāo)類的子類來覆蓋方法所以目標(biāo)類不能是 final 的被代理的方法也不能是 final。Spring 默認(rèn)策略是目標(biāo)類實(shí)現(xiàn)了接口就用 JDK 動(dòng)態(tài)代理沒有實(shí)現(xiàn)接口就用 CGLIB。// JDK 動(dòng)態(tài)代理示例 UserService userService new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, (proxyObj, method, args) - { System.out.println(before method: method.getName()); Object result method.invoke(userService, args); System.out.println(after method: method.getName()); return result; });6.3 動(dòng)態(tài)代理的實(shí)際應(yīng)用場景Spring AOP 的事務(wù)管理、日志切面、權(quán)限校驗(yàn)都是動(dòng)態(tài)代理的經(jīng)典應(yīng)用。MyBatis 里面更是把 JDK 動(dòng)態(tài)代理玩出了花我們用SqlSession.getMapper(UserMapper.class)拿到的 mapper 對象其實(shí)是個(gè) JDK 代理對象真正的邏輯在MapperProxy里通過解析接口上的注解動(dòng)態(tài)生成 SQL 并執(zhí)行。自己在項(xiàng)目里也經(jīng)?？梢杂脛?dòng)態(tài)代理做“無侵入增強(qiáng)”。比如統(tǒng)一打印方法入?yún)⒊鰠?、統(tǒng)一做重試機(jī)制、統(tǒng)一做接口耗時(shí)監(jiān)控。要注意的是Spring 的Transactional之所以失效一部分原因就是動(dòng)態(tài)代理失效——比如同一個(gè)類內(nèi)部調(diào)用this.method()走的不是代理對象自然不經(jīng)過事務(wù)增強(qiáng)邏輯。解決辦法是注入自身的代理對象或者把方法拆分到另一個(gè) Spring Bean 里。7. 高頻面試題與手撕算法沖刺7.1 八股文速記表格復(fù)習(xí)到最后把面試最高頻的幾道題整理成表格方便每天翻一遍。問題核心答案要點(diǎn)String 為什么不可變不可變保證字符串常量池和 hashCode 緩存的安全性避免被篡改底層用 final char[] 或 byte[] 保存 和 equals 區(qū)別 比較引用地址equals 默認(rèn)也是地址String 重寫后比較字符內(nèi)容HashMap 為什么線程不安全并發(fā) put 可能覆蓋數(shù)據(jù)、擴(kuò)容時(shí)可能丟數(shù)據(jù)JDK 7 甚至有死循環(huán)問題volatile 有什么用保證可見性、禁止指令重排但不保證原子性適合狀態(tài)標(biāo)志位synchronized 鎖升級(jí)過程無鎖 - 偏向鎖 - 輕量級(jí)鎖 - 重量級(jí)鎖鎖只能升級(jí)不能降級(jí)深拷貝和淺拷貝區(qū)別淺拷貝只復(fù)制引用深拷貝要復(fù)制對象內(nèi)部所有引用對象可序列化或逐字段 newJava 中有幾種這里說的是運(yùn)算符基礎(chǔ)類型比數(shù)值引用類型比地址為什么重寫 equals 要重寫 hashCode保證對象放進(jìn) HashSet/HashMap 時(shí)hashCode 一致才能找到對應(yīng)的桶有一個(gè)經(jīng)常考但很多人說不太清楚的細(xì)節(jié)String的不可變性具體表現(xiàn)是任何修改操作都會(huì)返回一個(gè)新的String對象原來那個(gè)對象內(nèi)容不變。這不僅是設(shè)計(jì)選擇還是解決多線程共享字符串安全問題的最樸素方案。7.2 手寫冒泡排序與快速排序算法手撕里排序?qū)儆诒乜柬?xiàng)。冒泡排序是入門重點(diǎn)在優(yōu)化——加一個(gè) swap 標(biāo)志位如果某一輪沒有任何交換說明數(shù)組已經(jīng)有序直接 break。public void bubbleSort(int[] arr) { 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]) { swap(arr, j, j 1); swapped true; } } if (!swapped) break; } }快速排序則是分治思想選擇基準(zhǔn)值把小于基準(zhǔn)的放左邊、大于基準(zhǔn)的放右邊然后遞歸處理左右子區(qū)間。面試時(shí)最重要的是寫對“分區(qū)”邏輯尤其是邊界條件。public void quickSort(int[] arr, int left, int right) { if (left right) return; int pivot partition(arr, left, right); quickSort(arr, left, pivot - 1); quickSort(arr, pivot 1, right); } private int partition(int[] arr, int left, int right) { int pivot arr[left]; while (left right) { while (left right arr[right] pivot) right--; arr[left] arr[right]; while (left right arr[left] pivot) left; arr[right] arr[left]; } arr[left] pivot; return left; }這里有一個(gè)高頻追問快速排序在最壞情況下比如數(shù)組已經(jīng)有序時(shí)間復(fù)雜度退化為 O(n^2)為什么還會(huì)被廣泛應(yīng)用答案是只要基準(zhǔn)值選取得當(dāng)期望復(fù)雜度是 O(n log n)工程實(shí)現(xiàn)里常用“三數(shù)取中”或者隨機(jī)選基準(zhǔn)來避免最壞情況而且它是原地排序空間復(fù)雜度只有 O(log n)緩存友好度比歸并排序更好。能把這個(gè)邏輯講清楚比單純背代碼更有說服力。復(fù)習(xí)這一步最大的收益從來不是“背會(huì)了什么”而是“發(fā)現(xiàn)哪里其實(shí)不會(huì)”。我這次重新過完集合和并發(fā)這兩塊最大的感受就是很多知識(shí)在項(xiàng)目里已經(jīng)用了無數(shù)遍但真要開口講清楚“為什么這樣設(shè)計(jì)”還是會(huì)卡殼。如果你也是在準(zhǔn)備面試建議不要只刷題拿我這份清單當(dāng)目錄每個(gè)點(diǎn)都試著合上電腦自己講一遍講不順的地方就是你應(yīng)該再花時(shí)間的地方。最后再分享一個(gè)小技巧每天早上花十分鐘在紙上默寫一遍 HashMap 的 put 流程和 ThreadPoolExecutor 的七個(gè)參數(shù)堅(jiān)持一周你上考場絕對比“看了一遍”的狀態(tài)穩(wěn)得多。 Java核心基礎(chǔ)復(fù)習(xí)筆記：集合、并發(fā)、JVM與動(dòng)態(tài)代理面試要點(diǎn)
本來這個(gè)系列的更新節(jié)奏被我拖了很久。前兩篇把Java基礎(chǔ)語法、面向?qū)ο蠛统Ｓ肁PI過了一遍這次趁著項(xiàng)目告一段落把集合框架、函數(shù)式編程、并發(fā)編程、JVM內(nèi)存模型以及反射動(dòng)態(tài)代理這五塊硬骨頭又快速擼了一遍。說實(shí)話每次復(fù)習(xí)都能發(fā)現(xiàn)幾個(gè)之前“以為自己知道其實(shí)沒吃透”的點(diǎn)尤其是HashMap底層和線程池參數(shù)真到了面試或者排查線上問題的時(shí)候才知道基礎(chǔ)扎實(shí)有多重要。這篇就當(dāng)我的復(fù)習(xí)筆記加面試前自檢清單如果你也在準(zhǔn)備Java面試或者想系統(tǒng)性地鞏固一遍核心基礎(chǔ)建議跟著過一遍遇到不熟的地方再往深挖。1. 先把“地基”踩實(shí)從環(huán)境變量到編譯運(yùn)行1.1 環(huán)境變量到底在配什么很多初學(xué)者在環(huán)境變量這一步就卡住了網(wǎng)上教程一大堆照著配完仍然java -version報(bào)錯(cuò)。其實(shí)環(huán)境變量的核心就三個(gè)JAVA_HOME、PATH、CLASSPATH。JAVA_HOME告訴系統(tǒng)和各種構(gòu)建工具JDK 到底裝在哪里。后續(xù) Maven、Tomcat、IDEA 找 JDK都是優(yōu)先讀這個(gè)變量。PATH讓命令行能在任意目錄直接執(zhí)行java、javac原理就是把%JAVA_HOME%\bin這個(gè)目錄塞進(jìn)系統(tǒng)搜索路徑。CLASSPATH指定類加載器去哪兒找第三方類庫。JDK 1.5 之后不配 CLASSPATH 也能編譯運(yùn)行基本程序因?yàn)榫幾g器默認(rèn)會(huì)找當(dāng)前目錄所以新手階段不用被它嚇住。配置時(shí)最容易被忽視的一個(gè)細(xì)節(jié)是改完環(huán)境變量后已經(jīng)打開的命令行窗口不會(huì)自動(dòng)生效必須重新開一個(gè)窗口。另一個(gè)高頻坑是多個(gè) JDK 版本殘留PATH里前面的 JDK 8 把后面的 JDK 17 擋住了導(dǎo)致java -version顯示的版本和JAVA_HOME對不上。排查方法很簡單在命令行執(zhí)行where java把實(shí)際命中的路徑找出來然后去PATH里調(diào)整順序。1.2 從 NoClassDefFoundError 聊到類路徑問題熱詞里有個(gè)非常典型的報(bào)錯(cuò)uncaught exception java.lang.noclassdeffounderror: java/applet/applet in thr?？吹絅oClassDefFoundError很多人的第一反應(yīng)是“類找不到”但嚴(yán)格來說它和ClassNotFoundException是兩回事。ClassNotFoundException運(yùn)行時(shí)通過Class.forName()或ClassLoader.loadClass()動(dòng)態(tài)加載類結(jié)果類路徑下壓根沒有這個(gè)類拋的是受檢異常是“主動(dòng)找類沒找到”。NoClassDefFoundError類在編譯期存在但運(yùn)行期類路徑變了或者某個(gè)靜態(tài)初始化塊拋了異常導(dǎo)致 JVM 無法完成這個(gè)類的定義。它是 Error不是 Exception說明 JVM 本身已經(jīng)處在不穩(wěn)定的狀態(tài)。出現(xiàn)java/applet/applet這種老掉牙的類找不到多半是項(xiàng)目里引用了某些老庫或者編譯目標(biāo)版本設(shè)置得太老運(yùn)行時(shí)卻用了高版本 JDK高版本 JDK 已經(jīng)移除了 Applet 相關(guān)模塊。解決辦法不是去網(wǎng)上隨便找個(gè) jar 塞進(jìn)去而是要檢查依賴樹看看誰傳遞依賴引入了這個(gè)老類再考慮排除或者升級(jí)依賴版本。順帶提一句Lombok 的you arent using a compiler supported by lombok報(bào)錯(cuò)也屬于“編譯期工具鏈不匹配”問題本質(zhì)是 JDK 版本和 Lombok 版本不兼容優(yōu)先升級(jí) Lombok 版本而不是去改編譯器參數(shù)。2. 集合框架不是背 API而是理解數(shù)據(jù)結(jié)構(gòu)2.1 集合整體結(jié)構(gòu)梳理Java 集合框架的核心接口就兩個(gè)方向Collection和Map。Collection下面分了List、Set、QueueMap則獨(dú)立一條線。理解這個(gè)體系不是為了面試時(shí)背出類名而是為了選型時(shí)腦子里有圖景。日常開發(fā)中最常用的選型大致可以按三條標(biāo)準(zhǔn)來判斷場景推薦實(shí)現(xiàn)原因需要有序、可重復(fù)、按下標(biāo)隨機(jī)訪問ArrayList底層數(shù)組隨機(jī)訪問 O(1)需要頻繁在中間插入/刪除、不關(guān)心隨機(jī)訪問LinkedList底層雙向鏈表增刪只改指針需要去重且不要求順序HashSet / LinkedHashSet基于 HashMap去重 O(1)需要按 key 快速查找 valueHashMap哈希表平均 O(1)并發(fā)環(huán)境下需要線程安全的 MapConcurrentHashMapCAS synchronized鎖粒度細(xì)2.2 ArrayList 擴(kuò)容與 LinkedList 的真相ArrayList 底層的擴(kuò)容機(jī)制是面試必問點(diǎn)。它默認(rèn)初始容量是 10每次擴(kuò)容變成原來的 1.5 倍oldCapacity (oldCapacity 1)。這里有個(gè)值得注意的細(xì)節(jié)如果一次性 addAll 添加大量元素按 1.5 倍逐步擴(kuò)會(huì)頻繁拷貝數(shù)組所以源碼里做了grow時(shí)判斷“實(shí)際需要的最小容量”來避免無意義的擴(kuò)容。LinkedList 的“增刪快”其實(shí)有很大前提。它確實(shí)在頭部和中間插入時(shí)不需要搬移元素但由于鏈表節(jié)點(diǎn)是分散在堆內(nèi)存的CPU 緩存命中率低再加上每次插入都要 new 一個(gè) Node 對象實(shí)際性能在絕大多數(shù)場景下反而不如 ArrayList。我做過一次簡單的基準(zhǔn)測試在 100 萬元素規(guī)模下中部插入 LinkedList 確實(shí)比 ArrayList 快但頭部插入因?yàn)?LinkedList 有頭指針勉強(qiáng)有優(yōu)勢尾部和隨機(jī)訪問則全面落后。結(jié)論很簡單能用 ArrayList 就用 ArrayListLinkedList 更多時(shí)候是退路而不是首選。2.3 HashMap 底層原理從數(shù)組鏈表到紅黑樹HashMap 是集合框架里邊最值得深挖的一個(gè)類。它的底層結(jié)構(gòu)在 JDK 1.8 之后是“數(shù)組 鏈表 紅黑樹”。put 一個(gè) key-value 時(shí)先對 key 的 hashCode 做一次擾動(dòng)運(yùn)算(h key.hashCode()) ^ (h 16)目的是讓高 16 位也參與尋址降低哈希沖突概率然后(n - 1) hash計(jì)算出數(shù)組下標(biāo)。鏈表什么時(shí)候轉(zhuǎn)紅黑樹這里有個(gè)容易記混的閾值鏈表長度超過 8并且數(shù)組長度大于等于 64才轉(zhuǎn)紅黑樹如果數(shù)組長度不足 64優(yōu)先擴(kuò)容而不是轉(zhuǎn)樹。為什么是 8因?yàn)樽髡咴谠创a注釋里說了遵循泊松分布在負(fù)載因子 0.75 的情況下鏈表長度達(dá)到 8 的概率已經(jīng)降到千萬分之六以下這時(shí)候轉(zhuǎn)紅黑樹是為了防止極端哈希沖突下查詢退化成 O(n)。理解這個(gè)概率之后就不會(huì)再死記硬背“鏈表長度大于 8 就轉(zhuǎn)樹”這種片面的說法了。負(fù)載因子 0.75 也是個(gè)很經(jīng)典的設(shè)計(jì)。它是時(shí)間成本減少擴(kuò)容次數(shù)和空間成本避免數(shù)組太稀疏的折中。JDK 1.7 里 HashMap 的頭插法在并發(fā)擴(kuò)容時(shí)會(huì)形成環(huán)形鏈表導(dǎo)致 get 死循環(huán)1.8 改成尾插法之后死循環(huán)問題解決了但 HashMap 在并發(fā)下仍然會(huì)丟數(shù)據(jù)所以并發(fā)場景永遠(yuǎn)不要用 HashMap直接用ConcurrentHashMap。2.4 ConcurrentHashMap并發(fā)場景下的正解ConcurrentHashMap在 JDK 1.7 里用的是分段鎖Segment 繼承 ReentrantLock1.8 之后廢棄了分段鎖改成了CAS synchronized鎖住數(shù)組的每個(gè)桶節(jié)點(diǎn)。put 時(shí)先 CAS 判斷當(dāng)前桶是否為空為空就直接 CAS 插入不為空才 synchronized 鎖住頭節(jié)點(diǎn)再走鏈表或者紅黑樹的插入邏輯。這個(gè)設(shè)計(jì)把鎖粒度從“一段區(qū)域”縮小到“單個(gè)桶”并發(fā)度提升非常明顯而且能兼容之前用 HashMap 的絕大多數(shù)代碼。有朋友經(jīng)常把ConcurrentHashMap和Hashtable搞混。Hashtable是給整個(gè)表加一把重量級(jí)鎖并發(fā)讀都要串行早就該淘汰了。還有Collections.synchronizedMap()它本質(zhì)是包裝類把所有方法都加上 synchronized鎖粒度同樣粗。所以面試?yán)锉粏柕健熬€程安全的 Map 有哪些”最優(yōu)答案就是ConcurrentHashMap并且要說清楚它為什么比另外兩個(gè)更優(yōu)秀。3. Lambda 與 Stream切換到函數(shù)式思維3.1 Lambda 語法速記Lambda 表達(dá)式的本質(zhì)是“函數(shù)式接口的匿名實(shí)現(xiàn)”。所謂函數(shù)式接口就是只包含一個(gè)抽象方法的接口比如Runnable、Comparator、Function。語法結(jié)構(gòu)可以拆成三部分參數(shù)列表、箭頭、函數(shù)體。// 無參Runnable Runnable task () - System.out.println(run); // 單參Consumer ConsumerString consumer s - System.out.println(s); // 多參Comparator ComparatorInteger comparator (a, b) - a - b;剛學(xué) Lambda 時(shí)最容易蒙的是“什么時(shí)候能省略參數(shù)類型”。答案是只要編譯器能從上下文推斷出類型就可以省略。比如stream.map(s - s.length())編譯器知道s是String就不需要寫(String s) -。但如果是自己定義泛型方法推斷不出來的時(shí)候就必須顯式寫類型。3.2 Stream 常用操作與實(shí)戰(zhàn)Stream 的核心思想是“流水線”數(shù)據(jù)源經(jīng)過一系列中間操作最后由終端操作觸發(fā)計(jì)算。中間操作只做聲明不會(huì)真的計(jì)算這就是“惰性求值”。最常用的幾個(gè)操作filter按條件過濾map一對一轉(zhuǎn)換flatMap把一個(gè)元素展開成多個(gè)元素sorted排序可以傳 Comparatordistinct去重collect把流收集成 List/Set/Mapreduce把整個(gè)流歸約為一個(gè)值代碼示例統(tǒng)計(jì)訂單列表中金額超過 100 的訂單總額ListOrder orderList ...; double total orderList.stream() .filter(o - o.getAmount() 100) .mapToDouble(Order::getAmount) .sum();這里面有個(gè)很實(shí)用的點(diǎn)處理基本數(shù)值流的時(shí)候優(yōu)先用IntStream、LongStream、DoubleStream尤其是 sum、max、min 這類聚合操作比自己reduce再拆箱裝箱省心很多。熱搜詞里提到的“Java 字符串多行寫法”其實(shí)也適合放在這里說。JDK 15 正式引入了文本塊配合 Stream 處理多行文本非常舒服String json { name: Java, age: 27 } ;文本塊不需要寫一堆\n拼接代碼可讀性提升明顯但要注意它保留縮進(jìn)的方式以及后面不能直接跟內(nèi)容。3.3 Lambda 與 Stream 的坑第一個(gè)坑流只能消費(fèi)一次。一個(gè)Stream對象調(diào)用過終端操作之后就被關(guān)閉了再調(diào)用會(huì)拋IllegalStateException: stream has already been operated upon or closed。解決辦法就是用的時(shí)候現(xiàn)場生成新流不要反復(fù)用同一個(gè)變量。第二個(gè)坑Lambda 捕獲的局部變量必須是 effectively final。也就是說變量沒被顯式聲明為 final但后續(xù)沒有被重新賦值才能被 Lambda 引用。如果你在 Lambda 內(nèi)部嘗試修改外部變量的值編譯直接報(bào)錯(cuò)。想累加計(jì)數(shù)怎么辦用AtomicInteger或者干脆改成流里的收集器。第三個(gè)坑并行流parallelStream()在共享可變狀態(tài)時(shí)會(huì)出大問題。比如在并行流里往同一個(gè) ArrayList 里 add 數(shù)據(jù)不僅線程不安全而且結(jié)果隨機(jī)。真要并行處理數(shù)據(jù)優(yōu)先用collect做歸約保證每段線程處理獨(dú)立的數(shù)據(jù)塊最后合并結(jié)果。4. 并發(fā)編程線程、鎖與線程池4.1 創(chuàng)建線程的三種方式及選擇創(chuàng)建線程傳統(tǒng)上有三種方式繼承Thread、實(shí)現(xiàn)Runnable、實(shí)現(xiàn)Callable。繼承Thread的問題在于 Java 是單繼承繼承了 Thread 就不能繼承別的類了擴(kuò)展性太差實(shí)現(xiàn)Runnable沒有返回值也拿不到執(zhí)行結(jié)果Callable配合FutureTask可以拿到返回值并且能拋異常。ExecutorService executor Executors.newFixedThreadPool(4); FutureInteger future executor.submit(() - { Thread.sleep(2000); return 1 1; }); Integer result future.get(); // 這里會(huì)阻塞等待任務(wù)完成熱搜詞“java線程等待都完成”對應(yīng)的就是這種場景。除了Future.get()逐個(gè)等待更優(yōu)雅的是用CountDownLatch或者CompletableFuture.allOf()。CountDownLatch 適合“等 N 個(gè)線程都做完再繼續(xù)主線程”的場景比如批量導(dǎo)出報(bào)表等所有分片查詢線程結(jié)束后統(tǒng)一生成 ZIP 文件。4.2 synchronized 與 JUC 鎖到底怎么選synchronized從 JDK 1.6 開始經(jīng)歷了鎖升級(jí)過程無鎖 - 偏向鎖 - 輕量級(jí)鎖 - 重量級(jí)鎖。鎖只能升級(jí)不能降級(jí)這是為了在不同競爭程度下尋找性能平衡。重量級(jí)鎖依賴操作系統(tǒng)的互斥量線程掛起喚醒涉及內(nèi)核態(tài)切換成本很高所以 JVM 才費(fèi)盡心思設(shè)計(jì)偏向鎖和輕量級(jí)鎖來減少這種切換。JUC包下的ReentrantLock則更靈活支持公平鎖、非公平鎖支持tryLock()超時(shí)控制支持多個(gè) Condition 條件變量。但偏偏這兩個(gè)鎖的選擇很多面試者說反了。簡單地說JDK 1.6 之后 synchronized 性能已經(jīng)和 ReentrantLock 差距不大能用 synchronized 就優(yōu)先用 synchronized因?yàn)樗?JVM 原生支持的使用簡單、不會(huì)因?yàn)橥浗怄i導(dǎo)致死鎖。需要公平鎖、超時(shí)中斷、多條件隊(duì)列這種高級(jí)特性時(shí)才考慮ReentrantLock。4.3 線程池參數(shù)面試?？忌a(chǎn)常踩坑ThreadPoolExecutor有七個(gè)核心參數(shù)corePoolSize核心線程數(shù)maximumPoolSize最大線程數(shù)keepAliveTime非核心線程的空閑存活時(shí)間unit時(shí)間單位workQueue任務(wù)隊(duì)列threadFactory線程工廠handler拒絕策略執(zhí)行流程一句話概括先讓核心線程跑核心線程滿了就進(jìn)隊(duì)列隊(duì)列滿了才創(chuàng)建非核心線程到最大線程數(shù)再滿就觸發(fā)拒絕策略。這個(gè)順序非常關(guān)鍵面試經(jīng)常搞混的是“隊(duì)列和最大線程數(shù)的先后關(guān)系”——很多人誤以為核心線程滿后直接創(chuàng)建新線程其實(shí)中間還隔著一個(gè)隊(duì)列。生產(chǎn)環(huán)境大忌就是用Executors.newFixedThreadPool()和newCachedThreadPool()。前者隊(duì)列是無界的LinkedBlockingQueue當(dāng)任務(wù)激增時(shí)隊(duì)列無限堆積內(nèi)存直接飆升后者最大線程數(shù)是Integer.MAX_VALUE任務(wù)一多線程瘋狂創(chuàng)建開銷極大。正確做法是用ThreadPoolExecutor的構(gòu)造函數(shù)顯式指定有界隊(duì)列和自定義拒絕策略。拒絕策略的四種實(shí)現(xiàn)也要掌握策略行為AbortPolicy直接拋 RejectedExecutionException默認(rèn)策略CallerRunsPolicy不用線程池由提交任務(wù)的線程自己執(zhí)行DiscardPolicy靜默丟棄任務(wù)DiscardOldestPolicy丟棄隊(duì)列中最早的任務(wù)再重試提交我個(gè)人偏愛CallerRunsPolicy因?yàn)樵诹髁扛叻鍟r(shí)它會(huì)把壓力傳回調(diào)用方起到天然背壓的效果不會(huì)靜默丟消息。5. JVM 內(nèi)存與異常從 StackOverflow 到 OOM 的排查思路5.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)快速瀏覽JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)可以按“線程共享”和“線程私有”來分線程私有虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器線程共享堆、方法區(qū)JDK 8 之后是元空間 Metaspace、運(yùn)行時(shí)常量池虛擬機(jī)棧里每個(gè)方法對應(yīng)一個(gè)棧幀棧幀里有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口。方法調(diào)用層級(jí)太深比如遞歸沒有出口就會(huì)拋StackOverflowError。堆里放對象實(shí)例絕大多數(shù) OOM 都發(fā)生在這里。程序計(jì)數(shù)器是唯一不會(huì) OOM 的區(qū)域因?yàn)樗淖饔弥皇怯涗洰?dāng)前線程執(zhí)行到哪一條字節(jié)碼指令空間幾乎可以忽略。5.2 高頻 OOM 類型與排查思路熱詞里有一個(gè)java: outofmemoryerror: insufficient memory這是比較典型的“內(nèi)存不足”提示。但在真實(shí) JVM 里OOM 還要細(xì)分成幾種類型原因排查方向Java heap space堆內(nèi)存不足對象太多或內(nèi)存泄漏抓 heap dump用 MAT 找大對象、查引用鏈GC overhead limit exceededGC 時(shí)間過長但回收效果極差優(yōu)先檢查堆大小配置再查泄漏Metaspace類元數(shù)據(jù)過多常由動(dòng)態(tài)生成類導(dǎo)致查 CGLIB/反射動(dòng)態(tài)代理生成類是否過量unable to create new native thread操作系統(tǒng)線程數(shù)達(dá)到上限ulimit、線程池參數(shù)、減少線程數(shù)排查堆內(nèi)存 OOM第一步不是改-Xmx而是抓現(xiàn)場?？梢约?JVM 參數(shù)-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump讓 JVM 在 OOM 時(shí)自動(dòng)導(dǎo)出堆轉(zhuǎn)儲(chǔ)文件。然后用jstat -gcutil pid看 GC 情況用jmap -histo pid看對象分布再用 MAT 分析 dump 文件的支配樹基本能定位到泄漏源。這里有個(gè)容易被忽略的經(jīng)驗(yàn)很多號(hào)稱“內(nèi)存泄漏”的問題其實(shí)是ThreadLocal沒清理或者是static集合一直持有對象引用。特別是ThreadLocal在線程池場景下如果線程不復(fù)用還好一旦線程長期存活且沒有調(diào)用remove()ThreadLocalMap 里的 Entry 會(huì)一直被線程持有形成內(nèi)存泄漏。5.3 異常體系與 try-with-resourcesJava 異常分兩大類Error和Exception。Error是 JVM 層面的嚴(yán)重問題比如StackOverflowError、OutOfMemoryError應(yīng)用程序通常不應(yīng)該去捕獲。Exception又分受檢異常IOException、SQLException和非受檢異常NullPointerException、IllegalArgumentException。受檢異常強(qiáng)制處理非受檢異常不強(qiáng)制。這個(gè)設(shè)計(jì)本意是好的但實(shí)際項(xiàng)目里經(jīng)常被濫用。我的習(xí)慣是外部環(huán)境導(dǎo)致的、可恢復(fù)的異常用受檢異常程序 bug 導(dǎo)致的、修代碼才能解決的問題用 RuntimeException。處理 IO 流時(shí)JDK 7 之后一定要用try-with-resources寫法自動(dòng)關(guān)閉資源。它有兩個(gè)好處第一不用在 finally 里寫一堆 null 判斷第二當(dāng)主體的異常和 close 的異常同時(shí)發(fā)生時(shí)close 的異常會(huì)被壓制suppressed主體異常優(yōu)先拋出。try (BufferedReader reader Files.newBufferedReader(path)) { String line reader.readLine(); } catch (IOException e) { log.error(read failed, e); }6. 反射與動(dòng)態(tài)代理框架底層的秘密6.1 反射核心 API反射是框架設(shè)計(jì)的基石Spring 的依賴注入、MyBatis 的 mapper 映射、Retrofit 的動(dòng)態(tài)接口實(shí)現(xiàn)底層全是反射和動(dòng)態(tài)代理。反射的入口是Class對象有三種獲取方式類名.class、對象.getClass()、Class.forName(全限定類名)。拿到Class之后可以獲取構(gòu)造器、方法、字段并繞過訪問控制去調(diào)用或修改。Class? clazz Class.forName(com.example.User); Constructor? constructor clazz.getDeclaredConstructor(String.class); constructor.setAccessible(true); // 繞過 private 構(gòu)造器檢查 Object user constructor.newInstance(張三);反射的性能天然比直接調(diào)用慢因?yàn)樗馕鲱愋汀z查訪問權(quán)限、走 JNI 后續(xù)的一系列動(dòng)態(tài)邏輯。不過現(xiàn)代 JVM 有針對反射的緩存優(yōu)化平時(shí)業(yè)務(wù)代碼里不需要過度擔(dān)心那點(diǎn)性能差但如果在一個(gè)高頻調(diào)用鏈路上反復(fù)用反射就該考慮在啟動(dòng)階段緩存Method對象而不是每次調(diào)用都getMethod()重新查找。6.2 JDK 動(dòng)態(tài)代理與 CGLIB 的區(qū)別動(dòng)態(tài)代理的面試考點(diǎn)集中在這兩種實(shí)現(xiàn)方式的原理和區(qū)別上。JDK 動(dòng)態(tài)代理基于接口。代理類在運(yùn)行時(shí)通過Proxy.newProxyInstance()生成要求目標(biāo)類必須實(shí)現(xiàn)接口。它本質(zhì)是構(gòu)造了一個(gè)實(shí)現(xiàn)了同樣接口的代理對象然后在InvocationHandler.invoke()方法里做增強(qiáng)邏輯。CGLIB基于繼承。通過生成目標(biāo)類的子類來覆蓋方法所以目標(biāo)類不能是 final 的被代理的方法也不能是 final。Spring 默認(rèn)策略是目標(biāo)類實(shí)現(xiàn)了接口就用 JDK 動(dòng)態(tài)代理沒有實(shí)現(xiàn)接口就用 CGLIB。// JDK 動(dòng)態(tài)代理示例 UserService userService new UserServiceImpl(); UserService proxy (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, (proxyObj, method, args) - { System.out.println(before method: method.getName()); Object result method.invoke(userService, args); System.out.println(after method: method.getName()); return result; });6.3 動(dòng)態(tài)代理的實(shí)際應(yīng)用場景Spring AOP 的事務(wù)管理、日志切面、權(quán)限校驗(yàn)都是動(dòng)態(tài)代理的經(jīng)典應(yīng)用。MyBatis 里面更是把 JDK 動(dòng)態(tài)代理玩出了花我們用SqlSession.getMapper(UserMapper.class)拿到的 mapper 對象其實(shí)是個(gè) JDK 代理對象真正的邏輯在MapperProxy里通過解析接口上的注解動(dòng)態(tài)生成 SQL 并執(zhí)行。自己在項(xiàng)目里也經(jīng)?？梢杂脛?dòng)態(tài)代理做“無侵入增強(qiáng)”。比如統(tǒng)一打印方法入?yún)⒊鰠?、統(tǒng)一做重試機(jī)制、統(tǒng)一做接口耗時(shí)監(jiān)控。要注意的是Spring 的Transactional之所以失效一部分原因就是動(dòng)態(tài)代理失效——比如同一個(gè)類內(nèi)部調(diào)用this.method()走的不是代理對象自然不經(jīng)過事務(wù)增強(qiáng)邏輯。解決辦法是注入自身的代理對象或者把方法拆分到另一個(gè) Spring Bean 里。7. 高頻面試題與手撕算法沖刺7.1 八股文速記表格復(fù)習(xí)到最后把面試最高頻的幾道題整理成表格方便每天翻一遍。問題核心答案要點(diǎn)String 為什么不可變不可變保證字符串常量池和 hashCode 緩存的安全性避免被篡改底層用 final char[] 或 byte[] 保存 和 equals 區(qū)別 比較引用地址equals 默認(rèn)也是地址String 重寫后比較字符內(nèi)容HashMap 為什么線程不安全并發(fā) put 可能覆蓋數(shù)據(jù)、擴(kuò)容時(shí)可能丟數(shù)據(jù)JDK 7 甚至有死循環(huán)問題volatile 有什么用保證可見性、禁止指令重排但不保證原子性適合狀態(tài)標(biāo)志位synchronized 鎖升級(jí)過程無鎖 - 偏向鎖 - 輕量級(jí)鎖 - 重量級(jí)鎖鎖只能升級(jí)不能降級(jí)深拷貝和淺拷貝區(qū)別淺拷貝只復(fù)制引用深拷貝要復(fù)制對象內(nèi)部所有引用對象可序列化或逐字段 newJava 中有幾種這里說的是運(yùn)算符基礎(chǔ)類型比數(shù)值引用類型比地址為什么重寫 equals 要重寫 hashCode保證對象放進(jìn) HashSet/HashMap 時(shí)hashCode 一致才能找到對應(yīng)的桶有一個(gè)經(jīng)常考但很多人說不太清楚的細(xì)節(jié)String的不可變性具體表現(xiàn)是任何修改操作都會(huì)返回一個(gè)新的String對象原來那個(gè)對象內(nèi)容不變。這不僅是設(shè)計(jì)選擇還是解決多線程共享字符串安全問題的最樸素方案。7.2 手寫冒泡排序與快速排序算法手撕里排序?qū)儆诒乜柬?xiàng)。冒泡排序是入門重點(diǎn)在優(yōu)化——加一個(gè) swap 標(biāo)志位如果某一輪沒有任何交換說明數(shù)組已經(jīng)有序直接 break。public void bubbleSort(int[] arr) { 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]) { swap(arr, j, j 1); swapped true; } } if (!swapped) break; } }快速排序則是分治思想選擇基準(zhǔn)值把小于基準(zhǔn)的放左邊、大于基準(zhǔn)的放右邊然后遞歸處理左右子區(qū)間。面試時(shí)最重要的是寫對“分區(qū)”邏輯尤其是邊界條件。public void quickSort(int[] arr, int left, int right) { if (left right) return; int pivot partition(arr, left, right); quickSort(arr, left, pivot - 1); quickSort(arr, pivot 1, right); } private int partition(int[] arr, int left, int right) { int pivot arr[left]; while (left right) { while (left right arr[right] pivot) right--; arr[left] arr[right]; while (left right arr[left] pivot) left; arr[right] arr[left]; } arr[left] pivot; return left; }這里有一個(gè)高頻追問快速排序在最壞情況下比如數(shù)組已經(jīng)有序時(shí)間復(fù)雜度退化為 O(n^2)為什么還會(huì)被廣泛應(yīng)用答案是只要基準(zhǔn)值選取得當(dāng)期望復(fù)雜度是 O(n log n)工程實(shí)現(xiàn)里常用“三數(shù)取中”或者隨機(jī)選基準(zhǔn)來避免最壞情況而且它是原地排序空間復(fù)雜度只有 O(log n)緩存友好度比歸并排序更好。能把這個(gè)邏輯講清楚比單純背代碼更有說服力。復(fù)習(xí)這一步最大的收益從來不是“背會(huì)了什么”而是“發(fā)現(xiàn)哪里其實(shí)不會(huì)”。我這次重新過完集合和并發(fā)這兩塊最大的感受就是很多知識(shí)在項(xiàng)目里已經(jīng)用了無數(shù)遍但真要開口講清楚“為什么這樣設(shè)計(jì)”還是會(huì)卡殼。如果你也是在準(zhǔn)備面試建議不要只刷題拿我這份清單當(dāng)目錄每個(gè)點(diǎn)都試著合上電腦自己講一遍講不順的地方就是你應(yīng)該再花時(shí)間的地方。最后再分享一個(gè)小技巧每天早上花十分鐘在紙上默寫一遍 HashMap 的 put 流程和 ThreadPoolExecutor 的七個(gè)參數(shù)堅(jiān)持一周你上考場絕對比“看了一遍”的狀態(tài)穩(wěn)得多。