JDK8升級JDK11最全實踐干貨來了

1、前言

截至目前（2023年），Java8發(fā)布至今已有9年，2018年9月25日，Oracle發(fā)布了Java11，這是Java8之后的首個LTS版本。那么從JDK8到JDK11，到底帶來了哪些特性呢？值得我們升級嗎？而且升級過程會遇到哪些問題呢？帶著這些問題，本篇文章將帶來完整的JDK8升級JDK11最全實踐。

2、為什么升級JDK11

1）性能提升

更好的垃圾收機制、更快的類加載器, 加快應(yīng)用程序的運行速度。綜合評估，從Java 8 升級到 Java 11，G1GC平均速度提升16.1%，ParallelGC為4.5%（基于OptaPlanner的用例基準測試表明）

2）特性和改進

局部變類型推斷、新的 API、HTTP/2客戶端、Lambda表達式的新特性等，這些新特性可以提高開發(fā)效率。

3）支持最新的技術(shù)和框架

許多新的技術(shù)和框架已經(jīng)或即將開始依賴于JDK11或以上版本，升級后可以保證應(yīng)用程序能夠分利用這些新的技術(shù)和框架。

4）長期支持版本

JDK11是Oracle官方發(fā)布的一個長期支持（LTS），意味著它將獲得長期的更新和支持，有助于保持用程序的穩(wěn)定性和可靠性。

5）行業(yè)趨勢

數(shù)據(jù)來自 New Relic 在2023年1月發(fā)布的Java生態(tài)報告，從下圖可以看出：

1、目前市面上有超過 56%的應(yīng)用程序使用了JDK 11，Java 8 的使用從2020年的84%降低到了現(xiàn)在的32%左右。大部分公司在這三年之間都升級到了JDK 11 或者 JDK 17這兩個LTS版本上面。 2、垃圾收集器使用情況來看，JDK11版本及以上G1使用率最高，占比高達65%

Java LTS版本百分比	垃圾回收器使用百分比

3、升級后GC效果

先給出結(jié)論：1、JDK11相對于JDK8，所有垃圾回收器的性能都有提升，特別是大內(nèi)存機器下G1的提升最明顯2、8G內(nèi)存以下的機器，推薦使用Parallel GC，如果特別追求低延遲，選擇犧牲吞吐量，可以使用G1，并設(shè)置期望的最大垃圾回收停頓時間來控制 3、8G及以上的大內(nèi)存機器，推薦使用G1 4、不推薦使用CMS，升級后從各項數(shù)據(jù)來看，CMS收集器都不如G1

我在JDOS平臺上選擇了不同配置的機器（2C4G、4C8G、8C16G），并分別使用JDK8和JDK11進行部署和壓測。

整個壓測過程限時60分鐘，用180個虛擬用戶并發(fā)請求一個接口，每次接口請求都創(chuàng)建512Kb的數(shù)據(jù)。最終產(chǎn)出不同GC回收器的各項指標(biāo)數(shù)據(jù)，來分析GC的性能提升效果。

以下是壓測的性能情況：

* 上面給出的GC升級效果，采用的是默認的配置，沒有做任何優(yōu)化，只提供參考。真正的GC調(diào)優(yōu)是個技術(shù)活，需要根據(jù)業(yè)務(wù)需求、機器配置和實際壓測效果等綜合評估來選出最合適的GC垃圾回收器。

* 不同垃圾回收器的特點：

1.Parallel GC - JDK 8及以下版本的默認收集器，關(guān)注吞吐量，嘗試在最小延遲的情況下盡快完成工作并提高吞吐量。

2.CMS -一個老年代收集器，基于標(biāo)記-清除算法實現(xiàn)，關(guān)注延遲，以最短回收停頓時間為目標(biāo)

3.Garbage First（G1）- JDK 9以后的默認收集器，G1 關(guān)注總體的性能，會嘗試在吞吐量和延遲之間做平衡。

4、JDK11帶來了哪些新特性

4.1、GC改進

默認垃圾回收器改為G1，廢棄CMS垃圾回收器

?G1特點：目標(biāo)是降低應(yīng)用程序的停頓時間并提高吞吐量。

引入ZGC垃圾回收器（可伸縮低延遲垃圾收集器）但由于JDK11中ZGC還不夠完善，推薦在JDK17中再使用穩(wěn)定版ZGC

?Full GC的停頓不超過10毫秒

?支持TB級堆內(nèi)存回收

?相對于G1吞吐量下降不超過15%

4.2、模塊化

Java9引入了對于模塊化軟件支持，而Java11進一步擴展了這種特性。模塊化讓應(yīng)用程序 更精簡，減少對其他類庫的依賴和冗余代碼，提高運行效率和安全性。

然而，目前不推薦使用模塊化，因為相關(guān)組件生態(tài)還不完善，并且模塊化帶來的價值不夠突出。具體原因請看后面章節(jié)的詳細分析：新特性實踐-模塊化。

4.3、語法增強

?局部變量推斷，引入var局部變量類型，允許開發(fā)人員省略通常不必要的局部變量類型初始化聲明

?Lambda表達式簡化，內(nèi)部可以使用var

?接口中可以定義私有方法，可以實現(xiàn)接口方法的訪問控制和代碼復(fù)用

4.4、API增強

?HTTPClient標(biāo)準化支持：強大而靈活的HTTP客戶端API，支持多協(xié)議（HTTP/2、WebSocket）、異步非阻塞、流操作和連接池等特性。ps：再也不需要用第三包HttpClient 工具包

?字符串方法增強：isBlank、lines、strip、stripLeading、stripTrailing和repeat

?Files增強：readString、WriteString

?InputStream增強：transferTo（流快速拷貝）

?stream增強，dropWhile（從集合中刪除滿足的）、takeWhile（從集合中獲取滿足的）、ofNullable

?集合工廠方法：Sets.of()、List.of()、Map.of()、Map.ofEntries()，舉例：Listlist = List.of("Java", "Python", "C++");

5、如何升級

5.1、升級應(yīng)用評估

?為保證穩(wěn)定性，我們優(yōu)先在新業(yè)務(wù)新應(yīng)用來落地實施JDK11的升級。

5.2、JDK選擇

自從2019年1月起，Oracle JDK后續(xù)的版本開始商用收費，所以推薦大家選擇OpenJDK11，OpenJDK和OracleJDK功能上沒有差異，支持免費商用。

OpenJDK11下載地址：https://jdk.java.net/archive/

5.3、GC配置

根據(jù)自身需求和機器配置選擇GC，不同GC的JVM啟動參數(shù)配置：

?G1垃圾回收器（JDK11默認，不需要手動配置）：-XX:+UseG1GC

?Parallel GC垃圾回收器：XX:+UseParallelGC

5.4、升級過程踩坑

整個升級過程還是比較簡單的，除了升級JDK版本，實際遇到的問題如下：

5.5、升級后驗證

升級后完成，做好單測和回歸測試，推薦能做個壓測驗證，防止影響線上服務(wù)穩(wěn)定性

6、新特性實踐-模塊化

Java一直是構(gòu)建大型應(yīng)用程序的主流語言之一。然而隨著Java生態(tài)系統(tǒng)中存在著大量庫和復(fù)雜的代碼塊之間關(guān)系難以理清的問題，構(gòu)建系統(tǒng)變得困難且超出了我們的理解和有效開發(fā)的范圍。特別是在使用繁多的Java存檔文件（Java Archive, JAR）時，這一問題變得更加突出。為了應(yīng)對這種復(fù)雜性，模塊化能夠很好地管理和減少代碼的復(fù)雜性。因此自Java9開始，引入了模塊化系統(tǒng)。通過模塊化，Java本身也得以進行模塊化改進。

6.1、模塊化是什么？

模塊化指的是JAVA平臺的模塊系統(tǒng)（Java Platform Module System），簡稱JPMS。JPMS引入一種新方式來組織和構(gòu)建Java應(yīng)用程序，它將代碼分為相互獨立、可復(fù)用的模塊。每個塊都有自己的命名空間，明確聲明并控制其他模塊的訪問權(quán)限。這種模塊化設(shè)計使得開發(fā)人員能夠更好地維護復(fù)雜的應(yīng)用程序，提高代碼的復(fù)用性、可維護性和安全性，同時提升應(yīng)用的加載速度和性能。最大的特點是可以定義模塊描述符來隔離module（Jar包）內(nèi)部類的訪問權(quán)限。

模塊化的幾點關(guān)鍵說明：

1）相對于JDK8的變動

?JDK9以后引入了一個新組件module：模塊描述符module-info.java，用于將一組相關(guān)的包放入一個組中。

?在Java8和更早的應(yīng)用程序中，應(yīng)用程序?qū)鳛轫敿壗M件，Java9以后應(yīng)用程序?qū)⒛K作為頂級組件

?一個模塊（Jar包）只能有一個module-info.java。

2）和maven的關(guān)系

模塊化并不是要替代maven，和maven本身并不沖突，maven定義jar之間的依賴關(guān)系，模塊化是對已經(jīng)依賴的jar下的包進行更細粒度依賴控制

3）如何兼容舊應(yīng)用

天然兼容舊應(yīng)用。為了向后兼容舊項目，一些庫本身并未模塊化，其仍然可以作為模塊在模塊路徑中使用，而這些庫在模塊路徑上時會被轉(zhuǎn)化為自動模塊，例如：jackson-databind-1.0.0.jar將成為自動模塊jackson.databind

6.2、帶來了哪些好處？

1）封裝和隔離，更好的訪問控制

模塊化允許開發(fā)者將代碼和資源封裝在獨立的模塊中。模塊之間可以明確地定義公開和私有的API，提供了更好的代碼隔離性和可維護性。

ps：新業(yè)務(wù)單應(yīng)用可以按照領(lǐng)域模型來進行多模塊的劃分，以避免代碼腐化。簡單舉例單應(yīng)用下存在產(chǎn)品.jar、訂單.jar。訂單依賴產(chǎn)品，通過模塊化的限制，訂單只能使用產(chǎn)品中明確對外暴露的類，這樣就避免傳統(tǒng)模式訂單.jar可能依賴了產(chǎn)品.jar中普通的類導(dǎo)致代碼腐化的問題，也降低后續(xù)領(lǐng)域服務(wù)拆分的復(fù)雜度

2）更好的可伸縮性，加載速度的提升

模塊化系統(tǒng)使得Java平臺更加可伸縮，通過模塊化定義，可以僅加載需要的模塊，從而提升加載類的效率，最終減少了應(yīng)用程序的內(nèi)存占用和啟動時間，同時打包后的程序也更小。

3）明確的依賴關(guān)系

模塊化系統(tǒng)要求在模塊之間明確定義依賴關(guān)系。在編譯或運行代碼之前，模塊系統(tǒng)會檢查模塊是否滿足所有依賴關(guān)系，從而導(dǎo)致更少的運行時錯誤。

4）安全

在JVM的最深層次上執(zhí)行強封裝，減少Java運行時的攻擊面，同時無法獲得對敏感內(nèi)部類的反射訪問。

6.3、如何使用

1）定義module-a.jar

包結(jié)構(gòu)如下：

com.jdt.a person Men.java reflect ReflectModel.java module-info.java

module-info文件內(nèi)容如下：

module module.a { //指令用于指定一個模塊中哪些包下的public對外是可訪問的，包括直接引入和反射使用 exports com.jdt.a.person; // 只能被反射調(diào)用，用于指定某個包下所有的類（公開、非公開）都只能在運行時可被別的模塊進行反射訪問。 opens com.jdt.a.refect; }

2）定義module-b.jar,包的pom中指定依賴了module-a

包結(jié)構(gòu)如下：

com.jdt.b test Test.java module-info.java

module-info文件內(nèi)容如下：

module module.b { //依賴a下的包 requires module.a; }

3）此時module-b.jar,在編寫編碼時，會遇到如下問題

6.4、實踐過程的坑

上面簡單介紹了模塊化的知識，具體在落地過程中，我們主要踩了以下的坑，供大家參考

1）依賴JSF包時無法模塊化

* JSF是京東內(nèi)部使用的高性能RPC框架

進行模塊化時，pom中依賴了jsf包，模塊定義如下：

module module.a { requires fastjson; //依賴jsf包名 requires jsf.lite; exports com.jd.jdk.test.module; }

此時編譯報錯如下：提示找不到模塊：jsf.lite，但是pom中明明指定依賴了jsf.lite

問題原因：

經(jīng)過一系列定位研究，發(fā)現(xiàn)jsf-lite包中，/META-INF/services下的文件org.glassfish.jersey.internal.spi.AutoDiscoverable里面寫的類是com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable，此類并未在當(dāng)前jsf.lite包中定義，屬于com.alibaba.fastjson包的。

但是我們的pom中明明也依賴了com.alibaba.fastjson包，為什么模塊化后，就找不到了呢？

主要原因在于模塊化遇到SPI（Service Provider Interface）時的約束：模塊化時，SPI機制要求配置中定義依賴的類必須本模塊定義的，不能是其他模塊的包（來自它不擁有的包），否則，此包將無法被模塊化

這樣也就解釋了，為什么上面jsf無法找到module的問題，jsf-lite里面設(shè)置了它不擁有的包：com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable，導(dǎo)致jsf-lite包無法被自動模塊化

解決方案：

1、聯(lián)系JSF團隊，升級JSF包，修復(fù)上面說的FastJsonAutoDiscoverable配置錯誤的問題。

2）拆包問題（模塊隔離）

模塊化約束：jdk9以上，使用模塊化時不支持拆分包的形式依賴

拆分包意味著兩個模塊包含相同的包，Java模塊系統(tǒng)不允許拆分包。拆分包始終是不正常的，而當(dāng)使用解析可傳遞依賴項的構(gòu)建工具（如Maven等）時，很容易出現(xiàn)同一個庫的多個版本，當(dāng)Java模塊系統(tǒng)檢測到一個包存在于模塊路徑上的多個模塊中時，就會拒絕啟動。

例如：

module-a.jar包結(jié)構(gòu)定義： com.foo.package A.java module-b.jar包結(jié)構(gòu)定義： com.foo.package B.java

當(dāng)module-c同時依賴module-a和module-b時，如上編譯時會報一個錯，Package com.foo.package in both module module.b and module module.a，這就是JAVA9的模塊隔離，要求只能從一個模塊（module）中讀取同一個包（package），不能跨模塊讀取。

解決方案：

如果在使用模塊化時，遇到了拆分包問題，無論如何都是無法繞過的。即使從用戶角度來看基于類路徑的應(yīng)用程序可以正確工作，你也最終需要處理這些問題。此時只能停用模塊化或升級jar包，避免拆分包問題

6.5、模塊化落地總結(jié)

目前不推薦使用模塊化，因為相關(guān)組件生態(tài)還不完善，并且模塊化帶來的價值不夠突出：

1.很多中間件都是基于jdk8構(gòu)建的，都有可能遇到模塊化兼容的問題，比如：jsf，需要jsf強制升級才可以使用模塊化

2.拆包問題無法解決，比如：aws-java-sdk-s3、fluent等。

7、總結(jié)

1、升級過程簡單，升級后可以使用更多新特性和更好的GC性能，所以建議升級到JDK11。

2、現(xiàn)階段不推薦使用模塊化，但是不用擔(dān)心會影響JDK11的升級。

另外聽說JDK17的 ZGC可以達到亞毫秒級停頓，但考慮到JDK11的ZGC還不是很穩(wěn)定，所以本次不做測試，后面升級到JDK17后再給大家分享ZGC壓測效果。

希望以上分享可以給大家?guī)韺嶋H的幫助。

系列文章：

JDK8升級JDK11最全實踐干貨來了

JDK11升級JDK17最全實踐干貨來了

你還在“垃圾”調(diào)優(yōu)？快來看看JDK17的ZGC如何解放雙手

JDK17實踐升級經(jīng)驗匯總

審核編輯 黃宇