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