是時候考慮升級 JDK 17 了_ZenDei技術網路在線

Spring，作為 Java EE 的事實規範，在2022年11月16日發佈了最新的 6.0.0 GA 版本。這個版本是框架後續新生代的初始版本，擁抱持續創新的 OpenJDK 和 Java 生態。新的版本以 Java 17+ 作為 baseline，並遷移至 Jakarta EE 9+（即，使用 ...

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 支持計劃：

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® 2015¹ 基準測試對前三個收集器的測試結果。

吞吐量

吞吐量測試結果

測試結果中，數值越高表示性能越好，可以看到，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，企業肯定會慢慢的融入升級的大軍之中。

參考文章：