1、前言
截至目前（2023年），Java8發(fā)布至今已有9年，2018年9月25日，Oracle發(fā)布了Java11，這是Java8之后的首個(gè)LTS版本。那么從JDK8到JDK11，到底帶來(lái)了哪些特性呢？值得我們升級(jí)嗎？而且升級(jí)過程會(huì)遇到哪些問題呢？帶著這些問題，本篇文章將帶來(lái)完整的JDK8升級(jí)JDK11最全實(shí)踐。
2、為什么升級(jí)JDK11
1）性能提升
更好的垃圾收機(jī)制、更快的類加載器, 加快應(yīng)用程序的運(yùn)行速度。綜合評(píng)估，從Java 8 升級(jí)到 Java 11，G1GC平均速度提升16.1%，ParallelGC為4.5%（基于OptaPlanner的用例基準(zhǔn)測(cè)試表明）
2）特性和改進(jìn)
局部變類型推斷、新的 API、HTTP/2客戶端、Lambda表達(dá)式的新特性等，這些新特性可以提高開發(fā)效率。
3）支持最新的技術(shù)和框架
許多新的技術(shù)和框架已經(jīng)或即將開始依賴于JDK11或以上版本，升級(jí)后可以保證應(yīng)用程序能夠分利用這些新的技術(shù)和框架。
4）長(zhǎng)期支持版本
JDK11是Oracle官方發(fā)布的一個(gè)長(zhǎng)期支持（LTS），意味著它將獲得長(zhǎng)期的更新和支持，有助于保持用程序的穩(wěn)定性和可靠性。
5）行業(yè)趨勢(shì)
數(shù)據(jù)來(lái)自 New Relic 在2023年1月發(fā)布的Java生態(tài)報(bào)告，從下圖可以看出：
- 目前市面上有 超過 56%的應(yīng)用程序使用了JDK 11，Java 8 的使用從2020年的84%降低到了現(xiàn)在的32%左右。大部分公司在這三年之間都升級(jí)到了JDK 11 或者 JDK 17這兩個(gè)LTS版本上面。
- 垃圾收集器使用情況來(lái)看，JDK11版本及以上 G1使用率最高，占比高達(dá)65%
3、升級(jí)后GC效果
先給出結(jié)論：
- JDK11相對(duì)于JDK8，所有垃圾回收器的性能都有提升，特別是大內(nèi)存機(jī)器下G1的提升最明顯
- 8G內(nèi)存以下的機(jī)器，推薦使用Parallel GC，如果特別追求低延遲，選擇犧牲吞吐量，可以使用G1，并設(shè)置期望的最大垃圾回收停頓時(shí)間來(lái)控制
- 8G及以上的大內(nèi)存機(jī)器，推薦使用G1 4、不推薦使用CMS，升級(jí)后從各項(xiàng)數(shù)據(jù)來(lái)看，CMS收集器都不如G1
我在JDOS平臺(tái)上選擇了不同配置的機(jī)器（2C4G、4C8G、8C16G），并分別使用JDK8和JDK11進(jìn)行部署和壓測(cè)。
整個(gè)壓測(cè)過程限時(shí)60分鐘，用180個(gè)虛擬用戶并發(fā)請(qǐng)求一個(gè)接口，每次接口請(qǐng)求都創(chuàng)建512Kb的數(shù)據(jù)。最終產(chǎn)出不同GC回收器的各項(xiàng)指標(biāo)數(shù)據(jù)，來(lái)分析GC的性能提升效果。
以下是壓測(cè)的性能情況：
* 上面給出的GC升級(jí)效果，采用的是默認(rèn)的配置，沒有做任何優(yōu)化，只提供參考。真正的GC調(diào)優(yōu)是個(gè)技術(shù)活，需要根據(jù)業(yè)務(wù)需求、機(jī)器配置和實(shí)際壓測(cè)效果等綜合評(píng)估來(lái)選出最合適的GC垃圾回收器。
* 不同垃圾回收器的特點(diǎn)：
-
Parallel GC - JDK 8及以下版本的默認(rèn)收集器，關(guān)注吞吐量，嘗試在最小延遲的情況下盡快完成工作并提高吞吐量。
-
CMS - 一個(gè)老年代收集器，基于標(biāo)記-清除算法實(shí)現(xiàn)，關(guān)注延遲，以最短回收停頓時(shí)間為目標(biāo)
-
Garbage First（G1）- JDK 9以后的默認(rèn)收集器，G1 關(guān)注總體的性能，會(huì)嘗試在吞吐量和延遲之間做平衡。
4、JDK11帶來(lái)了哪些新特性
4.1、GC改進(jìn)
默認(rèn)垃圾回收器改為G1，廢棄CMS垃圾回收器
? G1特點(diǎn)：目標(biāo)是降低應(yīng)用程序的停頓時(shí)間并提高吞吐量。
引入ZGC垃圾回收器（可伸縮低延遲垃圾收集器） 但由于JDK11中ZGC還不夠完善，推薦在JDK17中再使用穩(wěn)定版ZGC
? Full GC的停頓不超過10毫秒
? 支持TB級(jí)堆內(nèi)存回收
? 相對(duì)于G1吞吐量下降不超過15%
4.2、模塊化
Java9引入了對(duì)于模塊化軟件支持，而Java11進(jìn)一步擴(kuò)展了這種特性。模塊化讓應(yīng)用程序 更精簡(jiǎn)，減少對(duì)其他類庫(kù)的依賴和冗余代碼，提高運(yùn)行效率和安全性 。
然而，目前不推薦使用模塊化，因?yàn)橄嚓P(guān)組件生態(tài)還不完善，并且模塊化帶來(lái)的價(jià)值不夠突出。具體原因請(qǐng)看后面章節(jié)的詳細(xì)分析：新特性實(shí)踐-模塊化。
4.3、語(yǔ)法增強(qiáng)
? 局部變量推斷，引入var局部變量類型，允許開發(fā)人員省略通常不必要的局部變量類型初始化聲明
? Lambda表達(dá)式簡(jiǎn)化，內(nèi)部可以使用var
? 接口中可以定義私有方法，可以實(shí)現(xiàn)接口方法的訪問控制和代碼復(fù)用
4.4、API增強(qiáng)
? HTTPClient標(biāo)準(zhǔn)化支持：強(qiáng)大而靈活的HTTP客戶端API，支持多協(xié)議（HTTP/2、WebSocket）、異步非阻塞、流操作和連接池等特性。ps：再也不需要用第三包 HttpClient 工具包
? 字符串方法增強(qiáng)：isBlank、lines、strip、stripLeading、stripTrailing和repeat
? Files增強(qiáng)：readString、WriteString
? InputStream增強(qiáng)：transferTo（流快速拷貝）
? stream增強(qiáng)，dropWhile（從集合中刪除滿足的）、takeWhile（從集合中獲取滿足的）、ofNullable
? 集合工廠方法：Sets.of()、List.of()、Map.of()、Map.ofEntries()，舉例：List
5、如何升級(jí)
5.1、升級(jí)應(yīng)用評(píng)估
- 為保證穩(wěn)定性，我們優(yōu)先在新業(yè)務(wù)新應(yīng)用來(lái)落地實(shí)施JDK11的升級(jí)。
5.2、JDK選擇
自從2019年1月起，Oracle JDK后續(xù)的版本開始商用收費(fèi)，所以推薦大家選擇OpenJDK11，OpenJDK和OracleJDK功能上沒有差異，支持免費(fèi)商用。
OpenJDK11下載地址：https://jdk.java.net/archive/
5.3、GC配置
根據(jù)自身需求和機(jī)器配置選擇GC，不同GC的JVM啟動(dòng)參數(shù)配置：
- G1垃圾回收器（JDK11默認(rèn)，不需要手動(dòng)配置）：-XX:+UseG1GC
- Parallel GC垃圾回收器：XX:+UseParallelGC
5.4、升級(jí)過程踩坑
整個(gè)升級(jí)過程還是比較簡(jiǎn)單的，除了升級(jí)JDK版本，實(shí)際遇到的問題如下：
5.5、升級(jí)后驗(yàn)證
升級(jí)后完成，做好單測(cè)和回歸測(cè)試，推薦能做個(gè)壓測(cè)驗(yàn)證，防止影響線上服務(wù)穩(wěn)定性
6、新特性實(shí)踐-模塊化
Java一直是構(gòu)建大型應(yīng)用程序的主流語(yǔ)言之一。然而隨著Java生態(tài)系統(tǒng)中存在著大量庫(kù)和復(fù)雜的代碼塊之間關(guān)系難以理清的問題，構(gòu)建系統(tǒng)變得困難且超出了我們的理解和有效開發(fā)的范圍。特別是在使用繁多的Java存檔文件（Java Archive, JAR）時(shí)，這一問題變得更加突出。為了應(yīng)對(duì)這種復(fù)雜性，模塊化能夠很好地管理和減少代碼的復(fù)雜性。因此自Java9開始，引入了模塊化系統(tǒng)。通過模塊化，Java本身也得以進(jìn)行模塊化改進(jìn)。
6.1、模塊化是什么？
模塊化指的是JAVA平臺(tái)的模塊系統(tǒng)（Java Platform Module System），簡(jiǎn)稱JPMS。JPMS引入一種新方式來(lái)組織和構(gòu)建Java應(yīng)用程序，它將代碼分為相互獨(dú)立、可復(fù)用的模塊。每個(gè)塊都有自己的命名空間，明確聲明并控制其他模塊的訪問權(quán)限。這種模塊化設(shè)計(jì)使得開發(fā)人員能夠更好地維護(hù)復(fù)雜的應(yīng)用程序，提高代碼的復(fù)用性、可維護(hù)性和安全性，同時(shí)提升應(yīng)用的加載速度和性能。****最大的特點(diǎn)是可以定義模塊描述符來(lái)隔離module（Jar包）內(nèi)部類的訪問權(quán)限。
模塊化的幾點(diǎn)關(guān)鍵說(shuō)明：
1）相對(duì)于JDK8的變動(dòng)
- JDK9以后引入了一個(gè)新組件module：模塊描述符module-info.java，用于將一組相關(guān)的包放入一個(gè)組中。
- 在Java8和更早的應(yīng)用程序中，應(yīng)用程序?qū)鳛轫敿?jí)組件，Java9以后應(yīng)用程序?qū)⒛K作為頂級(jí)組件
- 一個(gè)模塊（Jar包）只能有一個(gè)module-info.java。
2）和maven的關(guān)系
模塊化并不是要替代maven，和maven本身并不沖突，maven定義jar之間的依賴關(guān)系，模塊化是對(duì)已經(jīng)依賴的jar下的包進(jìn)行更細(xì)粒度依賴控制
3）如何兼容舊應(yīng)用
天然兼容舊應(yīng)用。為了向后兼容舊項(xiàng)目，一些庫(kù)本身并未模塊化，其仍然可以作為模塊在模塊路徑中使用，而這些庫(kù)在模塊路徑上時(shí)會(huì)被轉(zhuǎn)化為自動(dòng)模塊，例如：jackson-databind-1.0.0.jar將成為自動(dòng)模塊jackson.databind
6.2、帶來(lái)了哪些好處？
1）封裝和隔離，更好的訪問控制
模塊化允許開發(fā)者將代碼和資源封裝在獨(dú)立的模塊中。模塊之間可以明確地定義公開和私有的API，提供了更好的代碼隔離性和可維護(hù)性。
ps：新業(yè)務(wù)單應(yīng)用可以按照領(lǐng)域模型來(lái)進(jìn)行多模塊的劃分，以避免代碼腐化。簡(jiǎn)單舉例單應(yīng)用下存在產(chǎn)品.jar、訂單.jar。訂單依賴產(chǎn)品，通過模塊化的限制，訂單只能使用產(chǎn)品中明確對(duì)外暴露的類，這樣就避免傳統(tǒng)模式訂單.jar可能依賴了產(chǎn)品.jar中普通的類導(dǎo)致代碼腐化的問題，也降低后續(xù)領(lǐng)域服務(wù)拆分的復(fù)雜度
2）更好的可伸縮性，加載速度的提升
模塊化系統(tǒng)使得Java平臺(tái)更加可伸縮，通過模塊化定義，可以僅加載需要的模塊，從而提升加載類的效率，最終減少了應(yīng)用程序的內(nèi)存占用和啟動(dòng)時(shí)間，同時(shí)打包后的程序也更小。
3）明確的依賴關(guān)系
模塊化系統(tǒng)要求在模塊之間明確定義依賴關(guān)系。在編譯或運(yùn)行代碼之前，模塊系統(tǒng)會(huì)檢查模塊是否滿足所有依賴關(guān)系，從而導(dǎo)致更少的運(yùn)行時(shí)錯(cuò)誤。
4）安全
在JVM的最深層次上執(zhí)行強(qiáng)封裝，減少Java運(yùn)行時(shí)的攻擊面，同時(shí)無(wú)法獲得對(duì)敏感內(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 {
//指令用于指定一個(gè)模塊中哪些包下的public對(duì)外是可訪問的，包括直接引入和反射使用
exports com.jdt.a.person;
// 只能被反射調(diào)用，用于指定某個(gè)包下所有的 public 類都只能在運(yùn)行時(shí)可被別的模塊進(jìn)行反射，并且該包下的所有的類及其乘員都可以通過反射進(jìn)行訪問。
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）此時(shí)module-b.jar,在編寫編碼時(shí)，會(huì)遇到如下問題
6.4、實(shí)踐過程的坑
上面簡(jiǎn)單介紹了模塊化的知識(shí)，具體在落地過程中，我們主要踩了以下的坑，供大家參考
1）依賴JSF包時(shí)無(wú)法模塊化
* JSF是京東內(nèi)部使用的高性能RPC框架
進(jìn)行模塊化時(shí)，pom中依賴了jsf包，模塊定義如下：
module module.a {
requires fastjson;
//依賴jsf包名
requires jsf.lite;
exports com.jd.jdk.test.module;
}
此時(shí)編譯報(bào)錯(cuò)如下：提示找不到模塊：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）時(shí)的約束：模塊化時(shí)，SPI機(jī)制要求配置中定義依賴的類必須本模塊定義的，不能是其他模塊的包（來(lái)自它不擁有的包），否則，此包將無(wú)法被模塊化
這樣也就解釋了，為什么上面jsf無(wú)法找到module的問題，jsf-lite里面設(shè)置了它不擁有的包：com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable，導(dǎo)致jsf-lite包無(wú)法被自動(dòng)模塊化
解決方案：
1、聯(lián)系JSF團(tuán)隊(duì)，升級(jí)JSF包，修復(fù)上面說(shuō)的FastJsonAutoDiscoverable配置錯(cuò)誤的問題。
2）拆包問題（模塊隔離）
模塊化約束：jdk9以上，使用模塊化時(shí)不支持拆分包的形式依賴
拆分包意味著兩個(gè)模塊包含相同的包，Java模塊系統(tǒng)不允許拆分包。拆分包始終是不正常的，而當(dāng)使用解析可傳遞依賴項(xiàng)的構(gòu)建工具（如Maven等）時(shí)，很容易出現(xiàn)同一個(gè)庫(kù)的多個(gè)版本，當(dāng)Java模塊系統(tǒng)檢測(cè)到一個(gè)包存在于模塊路徑上的多個(gè)模塊中時(shí)，就會(huì)拒絕啟動(dò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同時(shí)依賴module-a和module-b時(shí)，如上編譯時(shí)會(huì)報(bào)一個(gè)錯(cuò)，Package com.foo.package in both module module.b and module module.a，這就是JAVA9的模塊隔離，要求只能從一個(gè)模塊（module）中讀取同一個(gè)包（package），不能跨模塊讀取。
解決方案：
如果在使用模塊化時(shí)，遇到了拆分包問題，無(wú)論如何都是無(wú)法繞過的。即使從用戶角度來(lái)看基于類路徑的應(yīng)用程序可以正確工作，你也最終需要處理這些問題。此時(shí)只能停用模塊化或升級(jí)jar包，避免拆分包問題
6.5、模塊化落地總結(jié)
目前不推薦使用模塊化，因?yàn)橄嚓P(guān)組件生態(tài)還不完善，并且模塊化帶來(lái)的價(jià)值不夠突出：
-
很多中間件都是基于jdk8構(gòu)建的，都有可能遇到模塊化兼容的問題，比如：jsf，需要jsf強(qiáng)制升級(jí)才可以使用模塊化
-
拆包問題無(wú)法解決，比如：aws-java-sdk-s3、fluent等。
7、總結(jié)
- 升級(jí)過程簡(jiǎn)單，升級(jí)后可以使用更多新特性和更好的GC性能，所以 建議升級(jí)到JDK11。
- 現(xiàn)階段 不推薦使用模塊化，但是不用擔(dān)心會(huì)影響JDK11的升級(jí)。
另外聽說(shuō)JDK17的 ZGC可以達(dá)到亞秒級(jí)停頓，但考慮到JDK11的ZGC還不是很穩(wěn)定，所以本次不做測(cè)試，后面升級(jí)到JDK17后再給大家分享ZGC壓測(cè)效果。
希望以上分享可以給大家?guī)?lái)實(shí)際的幫助。
作者：京東科技?曲振富文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-712228.html
來(lái)源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請(qǐng)注明來(lái)源文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-712228.html
到了這里，關(guān)于JDK8升級(jí)JDK11最全實(shí)踐干貨來(lái)了的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
