Spring，作為 Java EE 的事實規范，在2022年11月16日發布了最新的 6.0.0 GA 版本，這個版本是框架后續新生代的初始版本，擁抱持續創新的 OpenJDK 和 Java 生態，新的版本以 Java 17+ 作為 baseline，并遷移至 Jakarta EE 9+（即，使用 jakarta 命名空間），
而在基礎設施方面，6.0 首次引入了 AOT 轉換，并為 Spring 應用程式背景關系提供了相應的 AOT 處理支持，這為 Spring Boot 3 的 GraalVM 原生鏡像提供了支持，原生鏡像的啟動速度非常快，并且能減少 Java 應用程式占用的記憶體，此外，新版本中支持虛擬執行緒，虛擬執行緒是輕量級的執行緒，能顯著減少寫入、維護的開銷，在并發應用中有較高的吞吐量，
其中很重要的一點是，新的 Spring 6.0 只支持 Java 17+ 了，并且在 Spring 相關的博客中也建議大家升級 JDK 到 17，
JDK LTS
下表是 Oracle 官方提供的 JDK 支持計劃：
那為什么是 JDK 17 呢？首先，在 JDK 8 之后只有 JDK 11 和 17 是 LTS（長期維護）版本，而實際上 11 又被大家公認為是過渡版本，對于 JDK 17，Oracle 官宣會提供支持到 2029 年，這給了業界一個相當長的期許，終于可以考慮替換已經誕生 8 年且在2019年1月已經停止公開更新的 JDK 8 了，
開發者關心的功能升級
下面我們看一下 JDK 從 8 升級到 17 的程序中，有哪些另開發者心動的功能呢？
介面私有方法（JDK9）
Java 8 支持在介面中撰寫默認（default）方法，而從 Java 9 開始，可以在介面中包含私有方法，私有介面方法不能是抽象的，私有方法只能在介面內部使用：
public interface CustomCalculator {
default int addEvenNumbers(int... nums) {
return add(n -> n % 2 == 0, nums);
}
default int addOddNumbers(int... nums) {
return add(n -> n % 2 != 0, nums);
}
private int add(IntPredicate predicate, int... nums) {
return IntStream.of(nums).filter(predicate).sum();
}
}
本地變數型別推斷（JDK10）
在 Java 10 之前版本中，當我們定義區域變數時，需要在賦值的左側提供顯式型別，并在賦值的右邊提供實作型別：
Person mike = new Person("Mike");
在 Java 10 以后，可以用下面的方式：
var john = new Person("john");
var doe = new Person("Doe");
// JDK 9 中提供了集合型別的新方法
var persons = List.of(john,doe);
// var 也可用于 for
for (var person : persons) {
System.out.println(person.name);
}
雖然我們寫代碼的時候方便了，但其實這是 JDK 提供的語法糖，在編譯成 class 檔案時，這些 var 還是會用實際的型別替換，
HTTP Client（JDK11）
java.net.http 包中的 HttpClient 最初在 JDK 9 中提供，后來在 JDK 10 升級，在 JDK 11 終于穩定成為標準功能，同時支持 HTTP/1.1 和 HTTP/2，下面是用 HttpClient 發一個 GET 請求的例子：
HttpClient httpClient = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_1_1)
.connectTimeout(Duration.ofSeconds(10))
.build();
HttpRequest request = HttpRequest.newBuilder()
.GET()
.uri(URI.create("https://httpbin.org/get"))
.setHeader("User-Agent", "Java 11 HttpClient Bot")
.build();
HttpResponse<String> response =
httpClient.send(request, HttpResponse.BodyHandlers.ofString());
HttpHeaders headers = response.headers();
headers.map().forEach((k, v) -> System.out.println(k + ":" + v));
System.out.println(response.statusCode());
System.out.println(response.body());
Switch 運算式（JDK14）
Switch 運算式是指可以通過 switch 進行賦值，在 Java 12 和 13 中陸續提供了功能預覽，而在 Java 14 中成為標準功能，看下面的示例：
private static int getValueViaYield(String mode) {
int result = switch (mode) {
case "a", "b":
yield 1; //使用 yield 提供回傳值
case "c":
yield 2;
case "d", "e", "f":
// do something here...
System.out.println("Supports multi line block!");
yield 3;
default:
yield -1;
};
return result;
}
也可以通過箭頭函式直接回傳，但是這兩種方式不能混用：
private static int getValueViaArrow(String mode) {
int result = switch (mode) {
case "a", "b" -> 1;
case "c" -> 2;
case "d", "e", "f" -> {
// do something here...
System.out.println("Supports multi line block!");
yield 3;
}
default -> -1;
};
return result;
}
文本塊（JDK15）
文本塊功能最開始在 Java 13 和 14 中提供預覽，最終在 Java 15 成型，有了這個功能，定義 HTML、SQL 陳述句或者 JSON，都會更加方便：
String java15DefineHtml = """
<html>
<body>
<p>Welcome to my blog</p>
</body>
</html>
""";
String java15DefineJson = """
{
"name":"世開Coding",
"type":"blog",
"URL":"https://blog.abmcode.com"
}
""";
instanceof 的模式匹配（JDK16）
在 JDK 16 以前，我們用 instanceof 是這樣的：
if (url instanceof String) {
String s = (String) url;
if (s.length() > 7) {
if (s.equalsIgnoreCase("Java Development Kit 16")) {
//...
}
}
}
那 JDK 16 之后呢，是這樣的，是不是瞬間清爽了：
// str 變數可以在后續邏輯中直接使用
if (url instanceof String str && str.length() > 5 && str.equalsIgnoreCase("Java Development Kit 16")){
// ...
}
Record（JDK16）
Java 被人詬病的一個原因是需要撰寫太多的模板代碼，在新建一個 POJO 時，我們需要提供 getters，setters，Lombok 通過 IDE 工具簡化了這個程序，而 Java 16 引入的 Record 型別也同樣減少了這種型別的樣板代碼，需要注意的是，Record 都是 final 的，且成員變數也都是 final 的，但是可以支持實作介面，例如，Runnable 或 Serializable，因此，簡單的方法引數封裝或者 DTO 都是 Record 適應的場景，
// 成員變數 name 和 url
public record WebsiteRecord(String name, String url) implements Serializable {
public WebsiteRecord {
if (!url.toLowerCase().startsWith("http")) {
throw new IllegalArgumentException("Invalid URL address:" + url);
}
System.out.println("New Website:" + name);
}
}
Sealed Class（JDK17）
我們都知道，帶有 final 修飾符的類是不能繼承的，那如果有些情況，我們還是希望能擴展類的功能，但是限制只有某些類能繼承呢？
在 Java 15 和 16 中引入了 Sealed Class 的功能預覽，在 Java 17 中作為標準功能提供，Sealed Class 只允許特定的類繼承，
// 只允許 Bicycle, Car, Truck 繼承
public abstract sealed class Vehicle permits Bicycle, Car, Truck {...}
// Car 帶有 final 修飾符，防止進一步擴展
public final class Car extends Vehicle {...}
// Truck 帶有 sealed 修飾符，只允許特定的類繼承
public sealed class Truck extends Vehicle permits PickTruck, CyberTruck {...}
// Bicycle 帶有 non-sealed 修飾符，任何類都可以繼續擴展
public non-sealed class Bicycle extends Vehicle {...}
// 任意擴展 Bicycle 類
public class Motor extends Bicycle {...}
使用 Sealed Class 還有幾點注意事項：
- 被許可的子類，必須在編譯時能被父類訪問到，
- 被許可的子類，必須直接繼承 Sealed 父類，
- 被許可的子類，必須帶有
final，sealed，non-sealed三個修飾符之一， - 被許可的子類必須在同一個 Java 模塊中，
小結
JDK 版本的升級會引入新的編程語言功能，能進一步提高開發者撰寫程式的效率，以前需要好幾行才能完成的功能，現在一行就搞定了，而新的概念和模塊推出，也可以優化軟體架構，減少對第三方庫的依賴，
性能提升
JDK 17 不只是提供了開發者關心的一些編程語言功能，在與舊版本的 JDK 相比，性能也得到了很大的提升，與 JDk 8 和 JDK 11 這兩個 LTS 相比，性能的提升主要得益于 JVM 中引入的新功能和改進，特別是 GC 方面的提升，
JDK 17 目前支持的垃圾收集器有：
- Parallel GC - JDK 8 和早期 JDK 的默認收集器，關注吞吐量，嘗試在最小延遲的情況下盡快完成作業并提高吞吐量，
- Garbage First（G1）- JDK 9 開始使用的默認收集器，G1 關注總體平衡的性能，會嘗試在吞吐量和延遲和吞吐量之間做平衡，
- ZGC（JDK 15） 和 Shenandoah GC（JDK 12）- 這兩個收集器關注延遲，通過犧牲吞吐量達到低延遲，ZGC 的啟用方式：
-XX:+UseZGC - Serial GC - 關注資源占用和啟動時間，這個收集器更像是一個簡化版的 Parallel GC，僅使用單執行緒進行處理，
可以看到，不同的收集器關注的性能方面是不一樣的，而決定使用哪個收集器，有時候也不是非常容易，首先我們需要搞清楚的是，我們的性能目標是什么？希望提高業務的吞吐量、減少業務的延遲還是減少資源的占用？當然，我們希望最好這幾點能同時滿足，但是 GC 是沒有辦法在每個方面都做到極致的，畢竟設計這些 GC 的時候，是目標場景做了一些權衡的，再看一下這三大需要提升的場景：
- 吞吐量 - 減少 GC 對完成單位時間內業務會話量的影響，
- 延遲 - 減少 GC 對單個業務會話的影響，
- 資源占用 - 減少 GC 使用的額外資源，
下面我們看看使用 16GB 堆記憶體和 SPECjbb? 20151 基準測驗對前三個收集器的測驗結果，
吞吐量
測驗結果中，數值越高表示性能越好，可以看到，JDK 17 中，ZGC 的性能提升了 20%，Parallel GC 和 G1 也分別有超過 10% 的提升，
延遲
從延遲的角度看，性能提升更加顯著，在縮短 GC 暫停時間所投入的作業有了回報，其中 G1 提升效果最佳，ZGC 也不錯，但是由于我們的基準測驗是測量應用程式的延遲，所以還有資料在這個圖表是看不到的，ZGC 在暫停時間上表現非常優異，下面的圖表展示暫停時間的提升（數值越小越好），我們可以看到 ZGC 的超預期性能：
在這里，我們分析原始性能數字（每個柱子上的數字），因為圖表按照資料尺度做了歸一化，看上去有點奇怪，正如我們所看到的，JDK 17 中的 ZGC 的表現遠低于其亞毫秒暫停時間的目標，G1 的目標是在延遲和吞吐量之間保持平衡，其暫停時間目標也低于其默認暫停時間目標 200ms，此圖表最右邊的柱子展示不同的收集器如何處理可伸縮性，ZGC 的設計是暫停時間不隨堆大小而增大，我們清楚地看到，當堆擴展到 128 GB 時就是這種情況，從暫停時間的角度來看，G1 比 Parallel 更好地處理較大的堆，因為 G1 也具有保持暫停時間目標的邏輯，
資源占用
圖中比較了三個不同收集器對本地記憶體的使用峰值，從結果看 Parallel 和 ZGC 都非常穩定，因此我們只能比較使用記憶體的絕對數值，而 G1 在這方面確實有所改進，
小結
無論使用哪種收集器，與舊版本相比，JDK 17 的整體性能都有很大的提升，在 JDK 8 中，默認使用 Parallel，但在 JDK 9 中改為了 G1，之后，G1 的改進速度就超過了 Parallel，但在有些情況下可能 Parallel 仍然是最好的選擇，而 ZGC（JDK 15）的加入，為我們提供了第三種高性能 GC 的選擇，
結語
開發環境方面，JDK 升級已經是大趨勢，Tomcat 10.1 已經支持 Jarkata EE，Hibernate ORM 6.1 也要求 JDK 11+，而最著名的開源框架 Spring 已經帶頭走在了更新 JDK 的康莊大道上，那么其他使用 Spring 的技術框架肯定會慢慢跟上，比如，Jmix 也會在明年一季度的版本中適配 Spring 6 和 Boot 3；JHipster 更加激進，從 Spring RC 版本推出時，已經開始嘗試適配，
運行環境方面，JDK 17+ 帶來的性能提升總體來說能達到約 20%，但是對于實際運行的生產系統，這點提升可能不足以吸引運維部門做升級，畢竟堆硬體也能提升性能，而升級 JDK 還有可能引入新的安全問題，
因此，對開發人員來說，我們建議盡早切換至 JDK 17，嘗試新的語言特性，提升自己的技能，盡管可能會面臨新 JDK 中的安全問題，但是由于新版本正處在積極開發支持中，如果有問題也會很快解決，而對于企業來說，如果擔心安全問題影響線上系統，可以緩一緩再使用，另外，如果考慮去 Oracle，則可以選擇 OpenJDK，一些有實力的大企業也會使用 OpenJDK 構建自己的 JDK，
隨著技術的發展，越來越多的框架的新版本都會陸續支持新版的 JDK，企業肯定會慢慢的融入升級的大軍之中，
參考文章：
- https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga
- https://reflectoring.io/java-release-notes/
- https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/538296.html
標籤：Java