1、前言

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

2、爲什麼升級JDK11

1）性能提升

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

2）特性和改進

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

3）支持最新的技術和框架

許多新的技術和框架已經或即將開始依賴於JDK11或以上版本，升級後可以保證應用程序能夠分利用這些新的技術和框架。

4）長期支持版本

JDK11是Oracle官方發佈的一個長期支持（LTS），意味着它將獲得長期的更新和支持，有助於保持用程序的穩定性和可靠性。

5）行業趨勢

數據來自 New Relic 在2023年1月發佈的Java生態報告，從下圖可以看出：

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

3、升級後GC效果

先給出結論：

JDK11相對於JDK8，所有垃圾回收器的性能都有提升，特別是大內存機器下G1的提升最明顯
8G內存以下的機器，推薦使用Parallel GC，如果特別追求低延遲，選擇犧牲吞吐量，可以使用G1，並設置期望的最大垃圾回收停頓時間來控制
8G及以上的大內存機器，推薦使用G1 4、不推薦使用CMS，升級後從各項數據來看，CMS收集器都不如G1

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

整個壓測過程限時60分鐘，用180個虛擬用戶併發請求一個接口，每次接口請求都創建512Kb的數據。最終產出不同GC回收器的各項指標數據，來分析GC的性能提升效果。

以下是壓測的性能情況：

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

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

Parallel GC - JDK 8及以下版本的默認收集器，關注吞吐量，嘗試在最小延遲的情況下儘快完成工作並提高吞吐量。
CMS - 一個老年代收集器，基於標記-清除算法實現，關注延遲，以最短回收停頓時間爲目標
Garbage First（G1）- JDK 9以後的默認收集器，G1 關注總體的性能，會嘗試在吞吐量和延遲之間做平衡。

4、JDK11帶來了哪些新特性

4.1、GC改進

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

◦ G1特點：目標是降低應用程序的停頓時間並提高吞吐量。

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

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

◦ 支持TB級堆內存回收

◦ 相對於G1吞吐量下降不超過15%

4.2、模塊化

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

然而，目前不推薦使用模塊化，因爲相關組件生態還不完善，並且模塊化帶來的價值不夠突出。具體原因請看後面章節的詳細分析：新特性實踐-模塊化。

4.3、語法增強

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

◦ Lambda表達式簡化，內部可以使用var

◦ 接口中可以定義私有方法，可以實現接口方法的訪問控制和代碼複用

4.4、API增強

◦ HTTPClient標準化支持：強大而靈活的HTTP客戶端API，支持多協議（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()，舉例：List<String> list = List.of("Java", "Python", "C++");

5、如何升級

5.1、升級應用評估

爲保證穩定性，我們優先在新業務新應用來落地實施JDK11的升級。

5.2、JDK選擇

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

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

5.3、GC配置

根據自身需求和機器配置選擇GC，不同GC的JVM啓動參數配置：

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

5.4、升級過程踩坑

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

5.5、升級後驗證

升級後完成，做好單測和迴歸測試，推薦能做個壓測驗證，防止影響線上服務穩定性

6、新特性實踐-模塊化

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

6.1、模塊化是什麼？

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

模塊化的幾點關鍵說明：

1）相對於JDK8的變動

JDK9以後引入了一個新組件module：模塊描述符module-info.java，用於將一組相關的包放入一個組中。
在Java8和更早的應用程序中，應用程序將包作爲頂級組件，Java9以後應用程序將模塊作爲頂級組件
一個模塊（Jar包）只能有一個module-info.java。

2）和maven的關係

模塊化並不是要替代maven，和maven本身並不衝突，maven定義jar之間的依賴關係，模塊化是對已經依賴的jar下的包進行更細粒度依賴控制

3）如何兼容舊應用

天然兼容舊應用。爲了向後兼容舊項目，一些庫本身並未模塊化，其仍然可以作爲模塊在模塊路徑中使用，而這些庫在模塊路徑上時會被轉化爲自動模塊，例如：jackson-databind-1.0.0.jar將成爲自動模塊jackson.databind

6.2、帶來了哪些好處？

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

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

ps：新業務單應用可以按照領域模型來進行多模塊的劃分，以避免代碼腐化。簡單舉例單應用下存在產品.jar、訂單.jar。訂單依賴產品，通過模塊化的限制，訂單隻能使用產品中明確對外暴露的類，這樣就避免傳統模式訂單.jar可能依賴了產品.jar中普通的類導致代碼腐化的問題，也降低後續領域服務拆分的複雜度

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

模塊化系統使得Java平臺更加可伸縮，通過模塊化定義，可以僅加載需要的模塊，從而提升加載類的效率，最終減少了應用程序的內存佔用和啓動時間，同時打包後的程序也更小。

3）明確的依賴關係

模塊化系統要求在模塊之間明確定義依賴關係。在編譯或運行代碼之前，模塊系統會檢查模塊是否滿足所有依賴關係，從而導致更少的運行時錯誤。

4）安全

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

6.3、如何使用

1）定義module-a.jar

包結構如下：

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

module-info文件內容如下：

module module.a { 
    //指令用於指定一個模塊中哪些包下的public對外是可訪問的，包括直接引入和反射使用 
    exports com.jdt.a.person; 
    // 只能被反射調用，用於指定某個包下所有的 public 類都只能在運行時可被別的模塊進行反射，並且該包下的所有的類及其乘員都可以通過反射進行訪問。 
    opens com.jdt.a.refect; 
}

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

包結構如下：

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

module-info文件內容如下：

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

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

6.4、實踐過程的坑

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

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

* JSF是京東內部使用的高性能RPC框架

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

module module.a {
    requires  fastjson;
    //依賴jsf包名
    requires  jsf.lite;

    exports com.jd.jdk.test.module;
}

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

問題原因：

經過一系列定位研究，發現jsf-lite包中，/META-INF/services下的文件org.glassfish.jersey.internal.spi.AutoDiscoverable裏面寫的類是com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable，此類並未在當前jsf.lite包中定義，屬於com.alibaba.fastjson包的。

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

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

這樣也就解釋了，爲什麼上面jsf無法找到module的問題，jsf-lite裏面設置了它不擁有的包：com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable，導致jsf-lite包無法被自動模塊化

解決方案：

1、聯繫JSF團隊，升級JSF包，修復上面說的FastJsonAutoDiscoverable配置錯誤的問題。

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

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

拆分包意味着兩個模塊包含相同的包，Java模塊系統不允許拆分包。拆分包始終是不正常的，而當使用解析可傳遞依賴項的構建工具（如Maven等）時，很容易出現同一個庫的多個版本，當Java模塊系統檢測到一個包存在於模塊路徑上的多個模塊中時，就會拒絕啓動。

例如：

module-a.jar包結構定義：
com.foo.package
    A.java
    
module-b.jar包結構定義：
com.foo.package
    B.java

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

解決方案：

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

6.5、模塊化落地總結

目前不推薦使用模塊化，因爲相關組件生態還不完善，並且模塊化帶來的價值不夠突出：

很多中間件都是基於jdk8構建的，都有可能遇到模塊化兼容的問題，比如：jsf，需要jsf強制升級纔可以使用模塊化
拆包問題無法解決，比如：aws-java-sdk-s3、fluent等。

7、總結

升級過程簡單，升級後可以使用更多新特性和更好的GC性能，所以 建議升級到JDK11。
現階段 不推薦使用模塊化，但是不用擔心會影響JDK11的升級。

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

希望以上分享可以給大家帶來實際的幫助。

作者：京東科技曲振富

來源：京東雲開發者社區轉載請註明來源

JDK8升級JDK11最全實踐乾貨來了 | 京東雲技術團隊