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