做Java后臺十年從JDK 1.6一路用到今天我太清楚Java 8有多舒服了語法順手、生態(tài)成熟、面試八股文都有標(biāo)準(zhǔn)答案生產(chǎn)環(huán)境里一堆老系統(tǒng)靠它在扛。但這兩年形勢明顯不對了第三方框架集體要求JDK 17起步新同事開口就是虛擬線程和record老系統(tǒng)還在用ConcurrentHashMap加手動鎖硬扛并發(fā)。最麻煩的是Java 8已經(jīng)停止免費商用更新安全補丁要么買商業(yè)授權(quán)要么就得自己盯公告。我所在團隊去年做了一個大決定把核心業(yè)務(wù)鏈路從Java 8整體升級到Java 21 LTS。這篇文章就是這次全鏈路架構(gòu)升級的完整復(fù)盤從版本節(jié)奏、核心特性、JVM底層演進到生產(chǎn)環(huán)境里踩過的兼容性大坑一一拆開講希望能給正在做同樣事的人省點時間。1. 先看清版本節(jié)奏為什么8到21不是一次簡單升級1.1 六年三代LTS你要跨過的不只是編譯版本很多人覺得升級JDK就是裝個新環(huán)境、改個java_home、把sourceCompatibility從1.8改成17就行這是最容易翻車的認(rèn)知。Java 8發(fā)布在2014年Java 21發(fā)布在2023年中間隔了整整9年、13個大版本類文件主版本號從52跳到65。換句話說你編譯出的class在JVM眼里已經(jīng)不是同一代的東西了更不用說JVM內(nèi)部的實現(xiàn)邏輯已經(jīng)換了好幾茬。更麻煩的是版本節(jié)奏本身變了。Java 8之前的LTS沒有明確規(guī)律但從Java 9開始Oracle采用每6個月一個功能版本、每2年一個LTS的節(jié)奏所以現(xiàn)在的主力LTS是11、17、21三個點。很多團隊從8直接跳到21中間跳過了9到20的所有過渡版本這雖然可行但代價是你得一次性吸收400多個JDK Enhancement Proposal帶來的變化。反過來看Java 8到11是第一次大的分水嶺模塊化和Java EE模塊移除都在這一段11到17是第二次強封裝和密封類都是這個階段定型的17到21才是新體驗爆發(fā)虛擬線程、record模式匹配、順序集合都在這里。所以我把這次升級拆成三個子階段來理解而不是一把梭。這里先給一個判斷如果你的系統(tǒng)還在Java 8現(xiàn)在最合適的落點是Java 21不是Java 11也不是Java 17。原因很簡單21是當(dāng)前最新的LTS支持周期最長而且虛擬線程這類能直接改變高并發(fā)編程模型的特性已經(jīng)正式發(fā)布。雖然17也很穩(wěn)但你已經(jīng)付出了升級成本再往前多走一步的邊際成本并不高省得幾年后又被迫再來一次。1.2 升級的直接收益性能、穩(wěn)定性和安全基線先算一筆賬不然老板那關(guān)也過不去。Java 8默認(rèn)的垃圾回收器是Parallel Scavenge加Parallel Old到Java 9開始默認(rèn)變G1Java 15之后ZGC和Shenandoah也都生產(chǎn)可用了。同樣的代碼光是換到G1默認(rèn)參數(shù)很多服務(wù)的Full GC頻率就能肉眼可見地下降因為G1把大堆并發(fā)標(biāo)記和可預(yù)測停頓做得比老回收器好得多。對于響應(yīng)時間敏感的服務(wù)Java 21下的ZGC可以做到亞毫秒級停頓這在Java 8時代是想都不敢想的事。安全方面同樣重要。Java 8的SSL/TLS棧默認(rèn)只到TLS 1.2而Java 11開始默認(rèn)支持TLS 1.3握手更快、密碼套件更安全。新版JDK還會在主版本更新里持續(xù)收緊jdk.tls.disabledAlgorithms把不安全的算法逐步禁用。對做支付、電商這類對安全合規(guī)有硬性要求的系統(tǒng)來說長期停留在Java 8等于一直在裸奔。還有一個很多人忽略的點Java 10之后對容器有了原生友好支持-XX:UseContainerSupport在8u191雖然也有但后續(xù)版本對容器CPU和內(nèi)存的識別更智能配合-XX:MaxRAMPercentage可以避免JVM在容器里按物理機內(nèi)存去設(shè)置堆大小這個后面實操部分會細(xì)講。2. 語言與API層面的核心特性盤點哪些能用、哪些要慎用2.1 日常最值得立即落地的特性var、record、switch表達式、文本塊升級到Java 21之后團隊最大的感受不是某個殺手級特性而是日常寫代碼的舒適度上來了。先從最沒風(fēng)險的開始var。它是Java 10引入的局部變量類型推斷只能用在局部變量上不能用在字段和方法返回值上。我一般只在MapString, ListOrderDetail這種長長泛型場景下用比如var details orderService.getDetails();讀起來清爽很多。但一定要克制如果你自己都看不出右邊new出來的是什么類型那讀者也猜不到這時候?qū)懭愋头炊谩Ｈ缓笫莚ecord這是Java 14預(yù)覽、16正式定稿的。一個record就是一組不可變數(shù)據(jù)的載體編譯器自動生成final字段、構(gòu)造器、equals、hashCode和toString。我用它替換了大量以前的POJO加LombokData組合最直觀的好處是代碼量驟減而且record天然是final的配合不可變集合就能把小對象的線程安全問題從根上解決。這里順帶說一個和“Java對象深度拷貝”相關(guān)的點record本身不可變不需要深度拷貝但如果你持有的record字段里有個ArrayList那它還是可變的我習(xí)慣在record的compact constructor里做防御性拷貝比如this.tags List.copyOf(tags);。switch表達式和文本塊也是上手即賺的特性。switch表達式從Java 14正式定稿箭頭語法不會再掉進fall-through陷阱配合yield可以返回值比傳統(tǒng)寫法清晰太多。文本塊從Java 15定稿寫SQL、JSON、XML模板時再也不用\n轉(zhuǎn)義堆成山了我們內(nèi)部一個報表系統(tǒng)升級后所有SQL模板全部重寫成文本塊可讀性上了兩個檔次。這些特性屬于“零成本改寫”只要代碼評審控制好范圍值得立刻推進。2.2 細(xì)粒度控制與不可變性密封類、模式匹配、順序集合Java 17定稿了密封類Java 21把record模式匹配和switch模式匹配也正式落地這幾樣?xùn)|西放一起才真正讓Java走了向“代數(shù)數(shù)據(jù)類型”靠近的路子。說人話就是你可以把類型層次畫死然后用一行switch把不同子類型的邏輯分干凈。舉個例子之前我們有個訂單狀態(tài)機用枚舉加一堆if-else判斷類型升級后用帶模式匹配的switch寫起來是這樣的sealed interface OrderEvent permits Created, Paid, Shipped, Cancelled {} record Created(long orderId, long userId) implements OrderEvent {} record Paid(long orderId, String payNo) implements OrderEvent {} record Shipped(long orderId, String carrier, String trackingNo) implements OrderEvent {} record Cancelled(long orderId, String reason) implements OrderEvent {} OrderResult handle(OrderEvent event) { return switch (event) { case Created(var id, var uid) - createOrder(id, uid); case Paid(var id, var payNo) - markPaid(id, payNo); case Shipped(var id, var carrier, var trackingNo) - ship(id, carrier, trackingNo); case Cancelled(var id, var reason) - cancel(id, reason); }; }編譯器能靜態(tài)幫你檢查所有分支是否窮盡漏一個case直接編譯不過這比運行期才知道漏分支回退到default強太多了。補一句和“Java怎么保證數(shù)據(jù)一致性”相關(guān)的心得record加密封類并不能直接替代分布式事務(wù)但它在單服務(wù)內(nèi)把狀態(tài)流轉(zhuǎn)在編譯期約束住極大減少了非法狀態(tài)轉(zhuǎn)換導(dǎo)致的數(shù)據(jù)不一致。順序集合是Java 21一個不太起眼但很實用的API。List、Deque、SortedSet這些接口以前沒有一個統(tǒng)一的“取第一個/最后一個”的方法老代碼里經(jīng)常見到list.get(list.size() - 1)這種寫法現(xiàn)在直接用getFirst()、getLast()還能reversed()得到反向視圖。老代碼里大量Collections.reverse(list)再遍歷的場景都可以簡化掉。2.3 全新的并發(fā)編程模型虛擬線程與結(jié)構(gòu)化并發(fā)虛擬線程是Java 21里最值得單獨開一節(jié)講的特性。它不是用來替代平臺線程的而是專門針對“高并發(fā)、高阻塞、IO密集”的場景。以前我們用Tomcat的200個線程池硬扛200個并發(fā)請求每個請求內(nèi)部還要調(diào)下游RPC、查數(shù)據(jù)庫、調(diào)緩存線程大部分時間都在等待IO。虛擬線程相當(dāng)于把“每請求一線程”的模型重新帶回來了但線程變成了由JVM調(diào)度的輕量級對象你可以輕松創(chuàng)建幾十萬個而不用害怕棧內(nèi)存爆掉。代碼里最常用的入口就是try (var executor Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(() - callRemoteService()); }使用上有一個在Java 21里必須注意的坑如果虛擬線程在synchronized塊里執(zhí)行阻塞IO會釘住pin底層載體線程導(dǎo)致載體線程被白白占住吞吐反而下降。這是因為synchronized的監(jiān)視器鎖實現(xiàn)不允許釋放載體線程。升級之后我專門做過一次代碼審查把所有熱點路徑上的synchronized改成ReentrantLock虛擬線程的吞吐立刻恢復(fù)正常。這個問題在后續(xù)JDK 24里會從JVM層面修復(fù)但你在21上生產(chǎn)使用就得先繞開。建議團隊定一條規(guī)矩凡是會跑在虛擬線程里的代碼鎖一律用java.util.concurrent.locks不要用內(nèi)置鎖。結(jié)構(gòu)化并發(fā)在21還是預(yù)覽特性我沒把它放進生產(chǎn)代碼但思路值得提前理解以前你提交多個子任務(wù)等結(jié)果時要么CountDownLatch要么CompletableFuture.allOf子任務(wù)和父任務(wù)的生命周期沒有綁定。結(jié)構(gòu)化并發(fā)是讓子任務(wù)的scope和父任務(wù)綁定要么全成功要么在第一個失敗時取消其余避免線程泄漏和“野火式”失控任務(wù)。它試用于編排類服務(wù)等轉(zhuǎn)正后再大規(guī)模推廣。3. 底層演進JVM運行時、GC與內(nèi)存管理的變化3.1 GC之變CMS已死G1要調(diào)參ZGC才是低延遲終點這一節(jié)不講清楚生產(chǎn)環(huán)境很容易上來就踩性能大坑。先說結(jié)論Java 8默認(rèn)的Parallel GC在9以后不再是默認(rèn)G1成為默認(rèn)回收器CMS在Java 9被標(biāo)記廢棄Java 14正式移除——所以如果升級后你還帶著-XX:UseConcMarkSweepGC啟動直接會報Unrecognized VM option這是最常見的第一道坎。G1本身的設(shè)計是“區(qū)域化堆 并發(fā)標(biāo)記 可預(yù)測停頓”但它默認(rèn)停頓目標(biāo)-XX:MaxGCPauseMillis200對很多應(yīng)用來說不夠激進。我們線上的一個大內(nèi)存服務(wù)堆里有12GB用G1時Young GC有時還是會到400ms以上后來把-XX:MaxGCPauseMillis調(diào)成100再把-XX:G1HeapRegionSize從默認(rèn)自動改為4MB停頓明顯平滑了。注意不要盲目把停頓目標(biāo)調(diào)太低比如設(shè)到10msG1會因為拼命壓縮回收量而導(dǎo)致吞吐下降CPU反而飆升。調(diào)G1一定要結(jié)合業(yè)務(wù)。吞吐優(yōu)先的就別太激進。如果你做的是交易、網(wǎng)關(guān)這類低延遲敏感服務(wù)直接考慮ZGC。ZGC從Java 15轉(zhuǎn)正Java 21又加入了分代版本叫Generational ZGC啟動參數(shù)是-XX:UseZGC -XX:ZGenerational。分代ZGC把熱對象和冷對象分開處理實測下來吞吐比第一代ZGC好不少停頓依然維持在亞毫秒級。不過ZGC適合大堆機器如果你服務(wù)的堆就1-2GBG1已經(jīng)夠了不必為了炫技上ZGC。還有個技巧升級后別急著換GC先在Java 21上保持G1默認(rèn)跑一周把GC日志和業(yè)務(wù)指標(biāo)拉出來對比確認(rèn)G1參數(shù)是否夠用再決定要不要上ZGC或Shenandoah。一次只變一個變量出了問題才知道是誰引起的。3.2 字符串、類加載與安全封裝的暗線變化這些變化平時看不見但一出問題就很詭異。第一個是Compact StringsJEP 254Java 9開始String的內(nèi)部存儲從char[]改成byte[]如果字符串內(nèi)容全是Latin-1可表示就用1字節(jié)每字符存儲否則用2字節(jié)。好處是很多中文字符串的內(nèi)存占用沒有變純ASCII場景內(nèi)存直接少一半。代價是charAt、substring這些操作的內(nèi)部實現(xiàn)變了所以千萬別再去反射String內(nèi)部的value字段很多老框架干過這種事在Java 9以后要么拿不到字段要么拿到的是字節(jié)數(shù)組而不是字符數(shù)組處理不當(dāng)就是亂碼。字符串拼接也從Java 9開始改成invokedynamic動態(tài)生成拼接邏輯老代碼里那種“手動new StringBuilder再拼”的微優(yōu)化已經(jīng)沒有意義了。第二個暗線是類加載與CDSClass Data Sharing。Java 10之后應(yīng)用類也能做CDS歸檔叫AppCDS這玩意兒對啟動時間的優(yōu)化非常直接。我們的一個服務(wù)原來啟動要8秒用AppCDS后降到5秒左右冷啟動擴容的體驗好了很多。有興趣的可以研究-XX:ArchiveClassesAtExit和-XX:SharedArchiveFile這兩個參數(shù)生產(chǎn)環(huán)境配合固定類路徑使用效果很穩(wěn)。第三個暗線是模塊化導(dǎo)致的強封裝。Java 9的模塊系統(tǒng)不只是新語法它對JDK內(nèi)部包做了強封裝。Java 8時代你可以隨便反射sun.misc.Unsafe、com.sun.*下面的內(nèi)部類Java 9到16默認(rèn)允許訪問但打印警告到Java 17之后--illegal-access參數(shù)直接被移除了所有JDK內(nèi)部包默認(rèn)不允許反射訪問。這會直接引爆一堆老庫下一部分詳細(xì)展開。3.3 反射、動態(tài)代理與字節(jié)碼最容易翻車的底層講完GC和模塊得專門留一段給反射和動態(tài)代理。因為這和“Java動態(tài)代理”、“Java反射”這些高頻面試點直接相關(guān)也是升級中報錯重災(zāi)區(qū)。Java 8到21JDK的動態(tài)代理本身沒變變的其實是底層對類定義的約束。老代碼用Proxy.newProxyInstance沒問題但CGLIB這類基于字節(jié)碼生成子類的庫在Java 9之后會撞上模塊封裝和類加載器的雙重變化生成子類時訪問被代理類所在的非開放模塊就可能拋InaccessibleObjectException或者IllegalAccessError。還有字節(jié)碼庫本身要跟得上新版class文件格式。Java 21的class文件主版本號是65如果你的ASM版本太老代理庫在生成或解析class時就會拋ClassFormatError: Unknown constant tag這類詭異異常。我們的經(jīng)驗是直接用官方升級矩陣核對一遍ASM至少9.5、ByteBuddy至少1.14.9、CGLIB必須換掉或者用基于ByteBuddy的替代實現(xiàn)、Lombok至少1.18.30。這些版本號我都是踩過坑才記住的下面第5部分會做一張速查表。4. 生產(chǎn)級升級實操從評估到灰度發(fā)布的完整路徑4.1 升級前的資產(chǎn)盤點與兼容性矩陣升級的第一步不是裝JDK而是盤點。我把盤點拆成四張清單服務(wù)清單、依賴清單、代碼清單、運行參數(shù)清單。服務(wù)清單要列出每個服務(wù)的JDK版本、框架版本、負(fù)責(zé)人和最近發(fā)版節(jié)奏依賴清單用mvn dependency:tree或Gradle dependencies把全量依賴導(dǎo)出來重點看Spring、Netty、MyBatis、Hutool這些基礎(chǔ)設(shè)施庫的版本要求代碼清單就是在代碼庫里搜索import sun.*、import com.sun.*、Class.forName、setAccessible(true)這些敏感用法運行參數(shù)清單收集線上每臺機器實際的JVM參數(shù)包括-XX前綴的所有配置。然后做一張兼容性矩陣表格式大概是這樣的組件Java 8Java 11Java 17Java 21備注Spring Boot 2.7.x支持支持需2.7.9不推薦Spring Boot 3才全面支持17Spring Boot 3.2.x不支持不支持支持支持包名要遷移到j(luò)akarta.*Lombok1.18.101.18.101.18.201.18.301.18.30前不支持class 65ByteBuddy1.9.x1.12.x1.14.x1.14.9Mockito等代理的底層ASM679.29.5老版本解析class 65直接崩Netty4.1.x4.1.x4.1.794.1.91高版本修復(fù)JDK17反射問題MyBatis3.5.x3.5.x3.5.x3.5.x主要看配套Spring版本這張表是動態(tài)維護的直到所有服務(wù)升級完畢。盤點完你會很清楚哪些服務(wù)可以快速升級哪些要等框架先升級哪些只能維持Java 8然后走網(wǎng)絡(luò)隔離。4.2 構(gòu)建鏈路的切換Maven/Gradle、編譯參數(shù)與依賴修復(fù)構(gòu)建鏈路的切換是整個升級里最需要耐心的一環(huán)。我建議的路線是先讓老代碼能跑在新JDK上再動編譯目標(biāo)。具體來說先用JDK 21運行時去跑一個用Java 8編譯的舊包驗證二進制兼容性。絕大多數(shù)場景下JVM 21能正常加載class 52的類但如果代碼里用到已被移除的API就會在運行期拋NoClassDefFoundError或NoSuchMethodError這時候按第5部分的清單一個個修。跑綠之后再把編譯目標(biāo)逐步往上提。Maven里最安全的做法是配置maven.compiler.release而不是source和target因為release會把編譯期用的JDK API也限制在對應(yīng)版本避免你開發(fā)機能編譯、生產(chǎn)環(huán)境卻找不到新API的問題。比如properties maven.compiler.release17/maven.compiler.release /propertiesGradle 7.6里用toolchain更干凈java { toolchain { languageVersion JavaLanguageVersion.of(21) } }第一次用JDK 21編譯時幾乎必現(xiàn)的報錯是“warning: [options] source value 8 is obsolete”以及一堆因為內(nèi)部API被封禁導(dǎo)致的編譯錯誤。內(nèi)部API的修復(fù)原則是能換公共API就換公共API比如sun.misc.BASE64Encoder換成java.util.Base64sun.reflect.Reflection.getCallerClass換成StackWalker。千萬不要習(xí)慣性加--add-opens——如果你發(fā)現(xiàn)某個依賴必須配合--add-opens java.base/java.langALL-UNNAMED才能跑那就說明這個依賴太老了優(yōu)先升級依賴本身而不是用JVM參數(shù)兜底。4.3 運行參數(shù)與容器化部署的調(diào)整運行參數(shù)這塊最核心的一句話老參數(shù)能刪就刪新參數(shù)按需再加。升級后第一件事就是把所有-XX:UseConcMarkSweepGC、-XX:UseParNewGC、PermSize、MaxPermGen這些在老JDK上已經(jīng)不存在的參數(shù)全部清掉留下一堆就是啟動即失敗。原來的-Xms、-Xmx這類參數(shù)可以保留但要配合容器新特性一起看。服務(wù)部署在Docker/K8s的話強烈建議改用比例式堆設(shè)置。Java 8時代我們經(jīng)常在啟動腳本里寫死-Xmx4g但同一個鏡像在2C4G和4C8G的Pod里跑寫死堆就很不合理。Java 10以后的推薦寫法是java -XX:InitialRAMPercentage50 -XX:MaxRAMPercentage50 -XX:MinRAMPercentage50 -jar app.jar這樣JVM會自動按容器可用內(nèi)存的50%來定初始堆和最大堆擴縮容時不用改鏡像。GC日志這塊也要注意Java 9開始統(tǒng)一日志系統(tǒng)以前那種-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:gc.log的組合已經(jīng)廢棄現(xiàn)在用-Xlog:gc*,gcmetaspaceinfo,gcheapinfo:file/logs/gc.log:time,uptime,level,tags:filecount10,filesize64m記錄GC日志并接入監(jiān)控是升級期間最重要的觀察手段別等出了問題再回憶發(fā)生了什么。JMX、遠(yuǎn)程調(diào)試這類運維端也要注意Java 9之后com.sun.management.jmxremote相關(guān)參數(shù)變了jconsole默認(rèn)連不上的情況很常見。建議統(tǒng)一用JMX_OPTS配合-Dcom.sun.management.jmxremote.portxxxx -Dcom.sun.management.jmxremote.rmi.portxxxx -Djava.rmi.server.hostnamexxx顯式設(shè)置避免端口隨機和hostname不對導(dǎo)致的連不上。4.4 灰度發(fā)布、回滾預(yù)案與監(jiān)控對比升級不可能一次性全量鋪開。我們的灰度策略是先在一個不核心的邊緣服務(wù)上用新鏡像跑三天觀察GC、CPU、內(nèi)存、錯誤率、SLA五個維度的指標(biāo)確認(rèn)沒問題后把核心服務(wù)的其中一個節(jié)點拉出來作為金絲雀節(jié)點流量控制在5%以內(nèi)跑至少兩個完整的業(yè)務(wù)高峰周期最后再逐步擴大到50%、100%。每個批次之間留足觀察窗口這中間不做任何其他發(fā)版保持變量干凈。回滾預(yù)案我建議做成“鏡像級回滾”舊JDK8的鏡像不刪K8s的Deployment保留上一版本出問題時一條kubectl rollout undo回去。因為升級鏈路里既有JDK變化也有依賴升級一旦出問題很難在幾十分鐘內(nèi)定位到具體代碼變更回滾永遠(yuǎn)比在線止血快。我還建議在網(wǎng)關(guān)層做一個基于流量的降級開關(guān)萬一下游服務(wù)升級后表現(xiàn)異常能快速把流量切到舊版實例。監(jiān)控對比方面重點看三組數(shù)據(jù)一是JVM自身指標(biāo)Heap使用率、GC次數(shù)、GC平均停頓、Full GC次數(shù)、線程數(shù)二是業(yè)務(wù)指標(biāo)P99/P95延遲、吞吐QPS、錯誤率、4xx/5xx比例三是基礎(chǔ)設(shè)施指標(biāo)CPU使用率、內(nèi)存占用、網(wǎng)絡(luò)IO。尤其是線程數(shù)Java 8服務(wù)里動輒上千的平臺線程在21上如果引入了虛擬線程線程數(shù)曲線會完全不一樣。用jcmd Thread.print和JFR分別抓新舊兩版的線程棧對比能發(fā)現(xiàn)很多隱性死鎖和長時間阻塞。5. 生產(chǎn)環(huán)境兼容性避坑清單按報錯分類的真實案例5.1 反射與模塊化InaccessibleObjectException全家桶升級到Java 17以上的第一個高發(fā)異常就是java.lang.reflect.InaccessibleObjectException報錯長這樣java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not opens java.lang to unnamed module ...我們線上有個老組件叫“動態(tài)字段映射器”靠反射遍歷對象所有字段做通用日志脫敏在Java 8上跑得好好的升級后直接啟動崩潰。定位思路很簡單先看棧頂?shù)姆瓷淠繕?biāo)是JDK內(nèi)部類還是你業(yè)務(wù)自己的類。如果是業(yè)務(wù)自己的類比如你的DTO在默認(rèn)包或未命名模塊里反射一般沒問題真正出事的是反射JDK內(nèi)部類比如String、Thread、ClassLoader。解決分三層第一層看能不能改代碼避免反射內(nèi)部類比如脫敏邏輯改用java.lang.reflect.RecordComponent和getRecordComponents去讀record字段第二層如果實在繞不開用--add-opens精準(zhǔn)開放對應(yīng)包比如-XX:AddOpens在Java 9里對應(yīng)的是--add-opens java.base/java.langALL-UNNAMED但這是臨時方案上了生產(chǎn)等于在封墻上開洞最好注明負(fù)責(zé)人和移除日期第三層升級到能兼容新JDK的庫版本大多數(shù)情況下這才是正解。記住一條底線不要寫一堆--add-opens java.base/sun.security.x509ALL-UNNAMED全網(wǎng)拷貝要理解每個開關(guān)對應(yīng)的代碼路徑不然安全掃描一上來全得返工。5.2 Java EE模塊移除JAXB、CORBA、Common Annotations去哪了第二個大坑是Java EE模塊整體被移出JDK。Java 11之前JDK里還內(nèi)置了JAXB、JAX-WS、CORBACORBA在11里已廢、Common Annotations這些Java EE API很多老系統(tǒng)在沒引任何依賴的情況下就能用javax.xml.bind做XML和Java對象互轉(zhuǎn)升級后發(fā)現(xiàn)直接NoClassDefFoundError: javax/xml/bind/JAXBException。我們團隊里有一個對接外部舊系統(tǒng)報文的服務(wù)就吃了這個虧XML解析用的全是JAXB升級后啟動直接掛。解決辦法是在pom里顯式引入JAXB依賴dependency groupIdjakarta.xml.bind/groupId artifactIdjakarta.xml.bind-api/artifactId version4.0.2/version /dependency dependency groupIdorg.glassfish.jaxb/groupId artifactIdjaxb-runtime/artifactId version4.0.5/version /dependency如果你的項目還是javax.*命名空間版本像Spring Boot 2.x那就用com.sun.xml.bind:jaxb-impl:2.3.9加javax.xml.bind:jaxb-api:2.3.1。這里要注意命名空間遷移Spring Boot 3和Jakarta體系已經(jīng)全面遷移到j(luò)akarta.*如果你升級JDK的同時也順手升級了Spring Boot 3那所有javax.servlet要改成jakarta.servletjavax.annotation.PostConstruct要換成jakarta.annotation.PostConstruct這類全局替換要單獨做一輪全量回歸特別容易漏。還有一些冷門但真實存在的APIjavax.activationJavaBeans Activation Framework在Java 9就標(biāo)記廢棄了Java 11移除Nashorn JS引擎在Java 15移除如果老代碼里用ScriptEngineManager跑過JS規(guī)則引擎得換GraalVM的js引擎或干脆用Java重寫規(guī)則Applet API在Java 17移除但這個對后臺服務(wù)基本沒影響。5.3 字節(jié)碼庫版本錯配ASM、CGLIB與ClassFormatError字節(jié)碼相關(guān)的坑最隱蔽因為報錯信息和你的業(yè)務(wù)代碼完全沒有直接關(guān)系。典型的報錯有啟動時拋java.lang.ClassFormatError: Unknown constant tag 67、java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version、運行期某個方法突然NoSuchMethodError。這些絕大多數(shù)時候都不是你的代碼問題而是字節(jié)碼工具庫解析不了新版本class文件。舉個例子我們的規(guī)則引擎里用了一個基于CGLIB的代理庫在運行時生成類Java 21環(huán)境下啟動就報IllegalAccessError: class X was not granted access to class Y。排查到最后是CGLIB舊版本生成子類時訪問了父類的內(nèi)部結(jié)構(gòu)而JDK 17強封裝之后這條路被堵死了。最終方案是把那個代理庫替換成基于ByteBuddy的實現(xiàn)ByteBuddy對JDK版本的適配做得最好。這里給出我在生產(chǎn)環(huán)境驗證過的字節(jié)碼庫版本底線可以直接抄作業(yè)字節(jié)碼/代理庫Java 17最低版本Java 21最低版本ASM9.29.5ByteBuddy1.12.01.14.9CGLIB3.3.0可能仍需改造不推薦使用Lombok1.18.221.18.30Mockitoinline4.5.05.5.0Spring含AOP5.3.206.0.x需Boot 3Javassist3.29.03.30.0為什么ASM和ByteBuddy的版本卡得這么死因為Java 21的class文件版本號是65ASM 9.2之前不認(rèn)識65看到新class就直接拋異常而Lombok 1.18.30之前不支持JDK 21的某些內(nèi)部編譯路徑注解處理后生成的代碼會帶不上必要的new權(quán)限。這類問題從報錯上看根本猜不到是“注解處理器版本太老”所以遇到詭異編譯錯誤時先懷疑字節(jié)碼庫版本別在業(yè)務(wù)代碼里瞎找。5.4 行為暗變默認(rèn)字符集、TLS、線程與GC的隱性差異最后這組坑是“不報錯但行為變了”最難發(fā)現(xiàn)。首當(dāng)其沖的是默認(rèn)字符集。Java 18開始JVM默認(rèn)字符集定為UTF-8之前是跟隨操作系統(tǒng)環(huán)境的。Java 8在中文Windows服務(wù)器上new String(bytes)默認(rèn)用的是GBK代碼里那些沒顯式指定字符集的地方以前“碰巧”是對的升級到Java 18以上之后全部變成UTF-8解析亂碼問題會集中爆發(fā)。我們的經(jīng)驗是全局搜索new String(、getBytes()、FileReader、InputStreamReader這些不帶字符集參數(shù)的調(diào)用全部改成顯式指定StandardCharsets.UTF_8。這一步建議在升級前就做因為改完的代碼在Java 8上也能跑風(fēng)險最低。第二個暗變是安全算法默認(rèn)值的收緊。Java 8默認(rèn)TLS 1.2Java 11開始TLS 1.3按優(yōu)先級啟用同時新版JDK對RSA密鑰長度、Diffie-Hellman密鑰大小、SHA-1證書鏈都有更嚴(yán)格的限制。如果你對外的服務(wù)要兼容一些特別老的客戶端比如只支持TLS 1.0的舊手機升級后握手大概率失敗。好在JSSE提供了jdk.tls.disabledAlgorithms、jdk.certpath.disabledAlgorithms這些安全屬性可以按需放開但放開之前一定要想清楚你真的是要為了老客戶端犧牲安全性嗎更靠譜的做法是讓老客戶端升級。第三個暗變是線程相關(guān)API的廢棄趨勢。Thread.stop()、Thread.suspend()、Thread.resume()雖然在Java 8里調(diào)了拋異常但還有一堆代碼在try-catch它們SecurityManager在Java 17標(biāo)記廢棄Java 24移除如果你在用自定義SecurityManager做權(quán)限隔離升級后要做好被移除的準(zhǔn)備。另外-Xss線程棧大小在不同JDK上的默認(rèn)值有變化如果升級后出現(xiàn)StackOverflowError增多不一定是遞歸寫錯也可能是線程棧默認(rèn)值變了用-XX:ThreadStackSize顯式控制即可。6. 常見問題與排查技巧實錄上線前后的高頻故障速查6.1 編譯期與啟動期報錯速查表把最常出現(xiàn)的報錯和一句話解法列成表排查時對著看能省不少時間報錯信息根本原因處理方案warning: [options] source value 8 is obsolete編譯目標(biāo)還停留在8使用--release 17/21錯誤: release version 8 not supportedsource/target低于8JDK 21最低支持8如報錯檢查是否誤用7程序包javax.xml.bind不存在Java EE模塊移除顯式引入JAXB依賴java.lang.reflect.InaccessibleObjectException反射訪問JDK內(nèi)部包被禁止修復(fù)代碼或精準(zhǔn)添加--add-opensjava.lang.NoClassDefFoundError: javax/annotation/...Common Annotations移除引入jakarta.annotation或javax.annotationjava.lang.NoSuchMethodError: X字節(jié)碼庫編譯時期的API和運行期不匹配升級字節(jié)碼庫/依賴組件版本java.lang.ClassFormatError: Unknown constant tagASM等工具不認(rèn)識class 65ASM升到9.5UnsupportedClassVersionErrorclass文件版本高于JVM支持范圍確認(rèn)JVM確實是21java_home別指錯編譯期還有一種常見情況是IDE里配了JDK 21但Maven默認(rèn)用的還是系統(tǒng)Java 8結(jié)果編譯報“錯誤: 不支持發(fā)行版本 21”。本質(zhì)是javac是從JDK 8里調(diào)出來的卻讓--release傳了21。解法是把Maven的JAVA_HOME或Gradle的toolchain明確指向JDK 21同時留意java_home環(huán)境變量的配置別讓IDE和命令行各用各的JDK。啟動期則最容易遇到“Unrecognized VM option”比如-XX:UseConcMarkSweepGC、-XX:UseParNewGC、-XX:PermSize。老運維腳本里的參數(shù)基本都要清一遍建議用java -XX:PrintFlagsFinal -version先把新JDK支持的參數(shù)列表拉出來看一遍凡是找不到的舊參數(shù)直接刪不要嘗試找替代品因為很多老參數(shù)的語義已經(jīng)被新GC重構(gòu)掉了。6.2 運行期內(nèi)存與性能問題排查升級完最怕的不是報錯而是明明跑起來了性能卻不如從前。我遇到過三種典型情況第一種是堆內(nèi)存占用猛漲排查后發(fā)現(xiàn)是String內(nèi)部表示從char[]變byte[]后某些依賴用反射讀String內(nèi)部字段失敗了被迫退化成拷貝大對象內(nèi)存自然漲第二種是GC停頓變大通常是G1自動選的region大小不合理或者代碼里大量大對象直接進Humongous區(qū)域這種要結(jié)合GC日志看第三種是CPU莫名其妙飆升多和--add-opens兜底方案有關(guān)因為每次反射訪問JDK內(nèi)部類都要經(jīng)過一層額外的安全檢查。遇到這類問題我的標(biāo)準(zhǔn)排查路徑是先用jcmd pid GC.heap_info看堆分布再用jcmd pid Thread.print抓線程棧看有沒有熱點阻塞然后開JFR記錄30分鐘重點看jdk.GCPhasePause、jdk.ObjectAllocationSample、jdk.JavaMonitorWait這幾類事件。Java 14開始JFR對生產(chǎn)幾乎零開銷直接在啟動參數(shù)里加上-XX:StartFlightRecordingfilename/logs/app.jfr,disktrue,dumponexittrue,settingsprofile出了問題拿記錄慢慢分析比上線后到處打日志強得多。還有一類隱蔽問題和服務(wù)啟動參數(shù)無關(guān)而是代碼里用了finalize()做資源清理。finalize在Java 9被標(biāo)記廢棄Java 18開始Object.finalize()被標(biāo)為for removal并且在JVM里走的是獨立清理線程升級后可能出現(xiàn)“object never finalized”導(dǎo)致連接泄漏。全局搜索finalize()方法統(tǒng)一改成Cleaner或者AutoCloseable加try-with-resources這也是處理“資源釋放怎么保證一致性”的一個標(biāo)準(zhǔn)答案。6.3 一套可復(fù)用的排查工具鏈最后把工具鏈整理出來。jdeps是分析依賴和模塊用得最多的工具升級前可以先跑jdeps --multi-release 21 -q --ignore-missing-deps target/app.jar它會告訴你哪些包依賴JDK內(nèi)部API哪些類找不到兼容性風(fēng)險一目了然。jcmd是綜合管理工具jcmd pid help能看到所有子命令VM.native_memory查本地內(nèi)存、GC.class_histogram看對象統(tǒng)計都很實用。jhsdb是老牌jmap/jhat的替代出crash時用jhsdb clhsdb或jhsdb hsdb做交互式分析。至于jmap -dump和jstack在JDK 8上還能用但在新版里我建議直接用JFR jmc替代因為JFR能記錄時間線比快照式的堆轉(zhuǎn)儲更容易定位“什么時候、發(fā)生了什么”。還有一個特別推薦的組合升級期間在灰度環(huán)境給每個節(jié)點加一個自動診斷的-XX:ErrorFile/logs/hs_err_pid%p.log和-XX:OnError腳本JVM崩潰時自動抓取現(xiàn)場保存配合統(tǒng)一日志里的GC時間線絕大多數(shù)疑難雜癥都能拼出完整故事。自從我把這套工具鏈固化成團隊SOP后再遇到詭異問題都能在一個小時內(nèi)給出初步結(jié)論。升級之后我的一些切身體會這次升級前后花了三個多月真正“切JDK版本”只用了兩周剩下的時間全部耗在依賴升級、代碼審查和灰度觀察上。我的體感是升級本身不難難的是管理層對“為什么要花這個時間”的理解。如果你的團隊也準(zhǔn)備動手建議先從一條邊緣鏈路做起把兼容性矩陣、監(jiān)控對比模板、回滾預(yù)案這三件套打磨順再橫向推廣。另外提醒一句升級期間新特性的引入要克制我們當(dāng)時只允許每個迭代落地一個特性避免又在同一時間引入虛擬線程又大規(guī)模重構(gòu)業(yè)務(wù)代碼變量太多就說不清到底是哪個改動帶來的問題。最后分享一個小技巧升級后把CI里的JDK設(shè)成21但留一條Java 8的老構(gòu)建job跑兼容性冒煙測試堅持一個季度能逼出很多意想不到的兼容性問題。Java 21不是終點但這個LTS的壽命足夠讓你安穩(wěn)很多年值得投入。