1.前言

JDK21 計劃23年9月19日正式發(fā)布，盡管一直以來都是“版隨意出，換 8 算我輸”，但這么多年這么多版本的折騰，若是之前的 LTS 版本JDK17你還覺得不錯，那 JDK21還是有必要關(guān)注一下，因為會有一批重要更新發(fā)布到生產(chǎn)環(huán)境中，特別是被眾人期待已久的虛擬線程，縱然說這東西我感覺沒有必要的用不到，需要的早已轉(zhuǎn)go了，但作為近幾年JDK一個“重要”的更新，在實際開發(fā)應(yīng)用中還是有相當(dāng)?shù)膬r值。如果說之前的 JDK17你還覺得沒必要折騰，那 JDK21確實有必要關(guān)注一下了。因為 JDK21 引入了一種新型的并發(fā)編程模式。當(dāng)前 Java 中的多線程并發(fā)編程絕對是另我們都非常頭疼的一部分，感覺就是學(xué)起來難啃，用起來難用。但是轉(zhuǎn)頭看看使用其他語言的朋友們，根本就沒有這個煩惱嘛，比如 GoLang，感覺人家用起來就很絲滑因此這篇文章主要摘錄了這次更新中個人覺得相對有價值的幾點做個基本的介紹，想要體驗新功能的同學(xué)可以閱讀一下。

2.JDK21主要特型

2.1 結(jié)構(gòu)化并發(fā)

結(jié)構(gòu)化并發(fā)是一種編程范式，旨在通過提供結(jié)構(gòu)化和易于遵循的方法來簡化并發(fā)編程。使用結(jié)構(gòu)化并發(fā)，開發(fā)人員可以創(chuàng)建更容易理解和調(diào)試的并發(fā)代碼，并且不容易出現(xiàn)競爭條件和其他與并發(fā)有關(guān)的錯誤。在結(jié)構(gòu)化并發(fā)中，所有并發(fā)代碼都被結(jié)構(gòu)化為稱為任務(wù)的定義良好的工作單元。任務(wù)以結(jié)構(gòu)化方式創(chuàng)建、執(zhí)行和完成，任務(wù)的執(zhí)行總是保證在其父任務(wù)完成之前完成。

Structured Concurrency（結(jié)構(gòu)化并發(fā)）可以讓多線程編程更加簡單和可靠。在傳統(tǒng)的多線程編程中，線程的啟動、執(zhí)行和結(jié)束是由開發(fā)者手動管理的，因此容易出現(xiàn)線程泄露、死鎖和異常處理不當(dāng)?shù)葐栴}。

使用結(jié)構(gòu)化并發(fā)，開發(fā)者可以更加自然地組織并發(fā)任務(wù)，使得任務(wù)之間的依賴關(guān)系更加清晰，代碼邏輯更加簡潔。結(jié)構(gòu)化并發(fā)還提供了一些異常處理機(jī)制，可以更好地管理并發(fā)任務(wù)中的異常，避免因為異常而導(dǎo)致程序崩潰或數(shù)據(jù)不一致的情況。

除此之外，結(jié)構(gòu)化并發(fā)還可以通過限制并發(fā)任務(wù)的數(shù)量和優(yōu)先級，防止資源競爭和饑餓等問題的發(fā)生。這些特性使得開發(fā)者能夠更加方便地實現(xiàn)高效、可靠的并發(fā)程序，而無需過多關(guān)注底層的線程管理。

2.2 作用域值

作用域值是JDK 20中引入的一項功能，它允許開發(fā)人員創(chuàng)建受限于特定線程或任務(wù)的值。與線程本地變量類似，作用域值可以與虛擬線程和結(jié)構(gòu)化并發(fā)一起使用。通過作用域值，開發(fā)人員可以以結(jié)構(gòu)化的方式在任務(wù)和虛擬線程之間傳遞值，而無需復(fù)雜的同步或鎖定機(jī)制。這種特性非常適用于在應(yīng)用程序的不同部分之間傳遞上下文信息，如用戶身份驗證或請求特定數(shù)據(jù)。使用作用域值，我們可以更加優(yōu)雅地處理并發(fā)編程，并提高代碼的可讀性和維護(hù)性。

2.3 禁止動態(tài)加載代理

在運行時動態(tài)加載代理時發(fā)出警告。這些警告是為了未來的版本做準(zhǔn)備，以默認(rèn)禁止動態(tài)加載代理以提高系統(tǒng)完整性。為了平衡下面兩點

• 可維護(hù)性（對運行代碼進(jìn)行特殊修改的能力）
• 完整性（假設(shè)運行代碼不會被任意更改）

同時，還確保大多數(shù)不需要動態(tài)加載代理的工具不受影響。另外，該計劃要求保持動態(tài)加載代理的能力與“超能力”功能（如深度反射）的一致性。代理是一種組件，可以在應(yīng)用程序運行時更改應(yīng)用程序代碼。這個概念最初在2004年JDK 5的Java平臺分析架構(gòu)中引入，作為一種讓工具（特別是分析器）檢測類的方法。盡管代理最初被設(shè)計用于良性檢測，但高級開發(fā)人員發(fā)現(xiàn)它有一些用例，比如面向切面編程可以以任意方式改變應(yīng)用程序行為。同樣，代理也可以改變JDK本身等代碼。因此，JDK 5要求在命令行中指定代理，以確保應(yīng)用程序所有者批準(zhǔn)使用代理。在JDK 21中，計劃要求像啟動時加載代理一樣，需要應(yīng)用程序所有者批準(zhǔn)動態(tài)加載代理。這個變化將進(jìn)一步提高Java平臺的默認(rèn)系統(tǒng)完整性。

2.4 密鑰封裝機(jī)制API

• RSA密鑰封裝機(jī)制(RSA-KEM)

• 橢圓曲線集成加密方案(ECIES)等KEM算法

• 美國國家標(biāo)準(zhǔn)與技術(shù)研究院(NIST)后量子密碼學(xué)標(biāo)準(zhǔn)化過程的候選算法

另一個目標(biāo)是能在更高級別的協(xié)議(如傳輸層安全協(xié)議TLS)和密碼方案(如混合公鑰加密HPKE)中使用KEM。安全提供者可以用Java或本機(jī)代碼實現(xiàn)KEM算法,并包含RFC 9180中定義的Diffie-Hellman KEM(DHKEM)的實現(xiàn)。

2.5 棄用Windows 32位x86端口

提案的目標(biāo)是在未來的版本中移除特定端口。我們計劃更新構(gòu)建系統(tǒng)，以便在嘗試為Windows 32位x86配置構(gòu)建時發(fā)出錯誤消息。當(dāng)然，你可以通過新的配置選項來屏蔽這些錯誤消息。另外，我們還計劃將該端口及其相關(guān)功能標(biāo)記為已棄用，并刪除相關(guān)文檔。這樣做的原因是，我們注意到最后一個支持32位操作的Windows操作系統(tǒng)——Windows 10將于2025年10月結(jié)束生命周期。

2.6 匿名類和實例main方法預(yù)覽

旨在使Java語言進(jìn)化,以便學(xué)生在無需理解面向大型程序設(shè)計的語言特性的情況下編寫第一個Java程序。學(xué)生可以為單類程序編寫簡化的聲明,然后無縫地擴(kuò)展程序以使用更高級的特性,而不是使用Java的單獨方言。該提案不僅可以為Java提供平穩(wěn)的入門,而且可以減少編寫簡單Java程序(如腳本和命令行實用程序)的麻煩。

2.7 無名模式和變量的預(yù)覽

未命名模式匹配記錄組件,而不聲明組件的名稱或類型,未命名變量可以初始化但不使用。兩者都用下劃線字符_表示。該提案旨在通過省略不必要的嵌套模式來改善記錄模式的可讀性,并通過識別必須聲明但不會使用的變量來改善所有代碼的可維護(hù)性。

2.8 Generational ZGC（分代式 ZGC）

主要是增加了對分代的支持，提高垃圾回收的性能，看下整體描述

To ensure a smooth succession, we will initially make Generational ZGC available alongside non-generational ZGC. The -XX:+UseZGC command-line option will select non-generational ZGC; to select Generational ZGC, add the -XX:+ZGenerational option:

使用命令行選項 -XX:+UseZGC 將選擇非分代式 ZGC；要選擇分代式 ZGC，需要添加 -XX:+ZGenerational 選項。

$?java?-XX:+UseZGC?-XX:+ZGenerational?...

In a future release we intend to make Generational ZGC the default, at which point -XX:-ZGenerational will select non-generational ZGC. In an even later release we intend to remove non-generational ZGC, at which point the ZGenerational option will become obsolete.

要使用ZGC，你可以在命令行選項中添加-XX:+UseZGC。默認(rèn)情況下，它是非分代式的GC。如果想要使用分代式的ZGC，則需要將命令改為$ java -XX:+UseZGC -XX:+ZGenerational。而在未來的版本中，分代GC將成為默認(rèn)設(shè)置。

旨在通過為年輕對象和舊對象維護(hù)獨立的代來改善應(yīng)用程序性能。年輕對象往往很快就會死亡;維護(hù)獨立的代將允許ZGC更頻繁地收集年輕對象。運行在分代ZGC上的應(yīng)用程序應(yīng)會看到以下好處:分配中斷風(fēng)險更低,需要的堆內(nèi)存開銷更低,垃圾收集CPU開銷更低。這些好處應(yīng)該可以在吞吐量不明顯下降的情況下實現(xiàn)。

2.9 Record Patterns （記錄模式）

這個更新主要簡化了類型判斷與賦值的使用，類型判斷后無需顯式強(qiáng)制轉(zhuǎn)換且如果模式匹配，變量被初始化為要匹配的模板值， 這個說起來比較拗口，結(jié)合代碼大家理解下，我感覺還是挺有用的，這里我把JDK8 JDK17 JDK21 的實現(xiàn)進(jìn)行一個對比，大家就明白了。

//?As?of?Java?8
record?Point(int?x,?int?y)?{}

static?void?printSum(Object?obj)?{
????if?(obj?instanceof?Point)?{
????????Point?p?=?(Point)?obj;
????????int?x?=?p.x();
????????int?y?=?p.y();
????????System.out.println(x+y);
????}
}
//?As?of?Java?16
record?Point(int?x,?int?y)?{}

static?void?printSum(Object?obj)?{
????if?(obj?instanceof?Point?p)?{
????????int?x?=?p.x();
????????int?y?=?p.y();
????????System.out.println(x+y);
????}
}
//?As?of?Java?21
static?void?printSum(Object?obj)?{
????if?(obj?instanceof?Point(int?x,?int?y))?{
????????System.out.println(x+y);
????}
}

記錄模式和類型模式可以嵌套,以啟用強(qiáng)大的、聲明性的和可組合的數(shù)據(jù)導(dǎo)航和處理形式。該提案的目標(biāo)包括擴(kuò)展模式匹配以解構(gòu)記錄類的實例,添加嵌套模式以啟用更可組合的數(shù)據(jù)查詢。此特性與switch表達(dá)式和語句的模式匹配(見下文)共同演化。當(dāng)前的JEP將在繼續(xù)的經(jīng)驗和反饋的基礎(chǔ)上通過進(jìn)一步完善來最終確定該特性。除了少量編輯變化外,主要變化是刪除了記錄模式在增強(qiáng)的for語句標(biāo)題中出現(xiàn)的支持。該特性可能會在未來的JEP中重新提出。

2.10 Pattern Matching for switch （switch模式匹配）

switch 的模式匹配可以與Record Patterns結(jié)合使用 允許在任何對象上制定 switch 語句和表達(dá)式?？匆幌麓a例子：

static?String?formatterPatternSwitch(Object?obj)?{
????return?switch?(obj)?{
????????case?Integer?i?->?String.format("int?%d",?i);
????????case?Long?l????->?String.format("long?%d",?l);
????????case?Double?d??->?String.format("double?%f",?d);
????????case?String?s??->?String.format("String?%s",?s);
????????case?Position(int?x,?int?y)???->?String.format("String?%s,String?%s",?x,y);
????????default????????->?obj.toString();
????};
}

同時當(dāng)編譯器判斷所有分支都已涵蓋時，switch不再需要分支default，如下面的代碼

void?flyJava21(Direction?direction)?{?
????switch?(direction)?{
???????case?CompassDirection.NORTH?->?System.out.println("Flying?north");?
???????case?CompassDirection.SOUTH?->?System.out.println("Flying?south");
???????case?CompassDirection.EAST?->?System.out.println("Flying?east");
???????case?CompassDirection.WEST?->?System.out.println("Flying?west");?
???????case?VerticalDirection.UP?->?System.out.println("Gaining?altitude");?
???????case?VerticalDirection.DOWN?->?System.out.println("Losing?altitude");?
????}?
}

使得switch表達(dá)式或語句可以針對許多模式進(jìn)行測試,每個模式都有特定的操作,這樣復(fù)雜的數(shù)據(jù)查詢可以安全簡潔地表達(dá)。

該特性最初在JDK 17中提出,之后在JDK 18、JDK 19和JDK 20中進(jìn)行了完善。它將在JDK 21中通過進(jìn)一步的優(yōu)化最終確定。與前面的JEP相比,主要變化是刪除了帶括號的模式并允許合格的enum常量,如帶switch表達(dá)式和語句的常量。目標(biāo)包括通過允許模式出現(xiàn)在case標(biāo)簽中來擴(kuò)展switch表達(dá)式和語句的表達(dá)能力和適用范圍,允許switch的歷史 null敵意在需要時得到放松,并通過要求模式switch語句覆蓋所有潛在的輸入值來增加switch語句的安全性。另一個目標(biāo)是確保現(xiàn)有的switch表達(dá)式和語句繼續(xù)編譯而不變,并具有相同的語義。

2.11 向量API的第六個孵化器

該API表達(dá)了在支持的CPU體系結(jié)構(gòu)上可靠編譯為優(yōu)化向量指令的向量計算,其性能優(yōu)于等效的標(biāo)量計算。向量API此前在JDK 16至JDK 20中進(jìn)行了孵化。這個最新版本包括性能增強(qiáng)和錯誤修復(fù)。該提案的目標(biāo)包括清晰簡潔,與平臺無關(guān),并在x64和AArch64體系結(jié)構(gòu)上提供可靠的運行時編譯和性能。其他目標(biāo)包括在向量計算無法完全表示為向量指令序列時優(yōu)雅降級。

2.12 外部函數(shù)和內(nèi)存API的第三次預(yù)覽

使得Java程序能夠與Java運行時之外的代碼和數(shù)據(jù)進(jìn)行互操作。它通過高效調(diào)用外部函數(shù)和安全訪問外部內(nèi)存，使得Java程序能夠調(diào)用本機(jī)庫并處理本機(jī)數(shù)據(jù)，而無需使用JNI（Java本機(jī)接口）帶來的脆弱性和危險性。這個API之前在JDK 20和JDK 19中進(jìn)行了預(yù)覽。JDK 21預(yù)覽中的改進(jìn)包括增強(qiáng)布局路徑，以解引用地址布局，并引入新的元素；集中管理Arena接口中本地段生命周期；提供備用的本機(jī)鏈接器實現(xiàn)以及刪除VaList。該提案旨在提高易用性、性能、通用性和安全性。它的目標(biāo)不是重新實現(xiàn)JNI，也不會對JNI進(jìn)行任何改變。

2.13 虛擬線程

先看下官方對虛擬線程（Visual Threads）描述：

Today, every instance of java.lang.Thread in the JDK is a platform thread. A platform thread runs Java code on an underlying OS thread and captures the OS thread for the code's entire lifetime. The number of platform threads is limited to the number of OS threads.

A virtual thread is an instance of java.lang.Thread that runs Java code on an underlying OS thread but does not capture the OS thread for the code's entire lifetime. This means that many virtual threads can run their Java code on the same OS thread, effectively sharing it. While a platform thread monopolizes a precious OS thread, a virtual thread does not. The number of virtual threads can be much larger than the number of OS threads.

Virtual threads are a lightweight implementation of threads that is provided by the JDK rather than the OS. They are a form of user-mode threads, which have been successful in other multithreaded languages (e.g., goroutines in Go and processes in Erlang). User-mode threads even featured as so-called "green threads" in early versions of Java, when OS threads were not yet mature and widespread. However, Java's green threads all shared one OS thread (M:1 scheduling) and were eventually outperformed by platform threads, implemented as wrappers for OS threads (1:1 scheduling). Virtual threads employ M:N scheduling, where a large number (M) of virtual threads is scheduled to run on a smaller number (N) of OS threads.

以前Java中的線程是基于操作系統(tǒng)線程的平臺線程，按照1:1的模式調(diào)度，這導(dǎo)致線程的創(chuàng)建和執(zhí)行都非常耗資源，并且受系統(tǒng)限制。而現(xiàn)在的虛擬線程則是由JDK提供，可以將其視為在平臺線程基礎(chǔ)上創(chuàng)建的一批線程，它們有效地共享所屬的平臺線程即操作系統(tǒng)線程的資源，從而提高系統(tǒng)利用率，并且沒有數(shù)量限制。

目標(biāo)描述：

1、使采用簡單的按請求開啟線程方式編寫的服務(wù)器應(yīng)用程序能夠以接近最佳的硬件利用率進(jìn)行擴(kuò)展。

可以每個請求開啟一個虛擬線程，實現(xiàn)簡單直接的同時可以最大程度地提升硬件利用率；

2、使使用java.lang.Thread API的現(xiàn)有代碼能夠以最小的改動采用虛擬線程。

之前的多線程實現(xiàn)代碼可以在很小的修改下遷移到虛擬線程；

3、使用現(xiàn)有JDK工具方便地進(jìn)行虛擬線程的故障排除、調(diào)試和分析。

使用現(xiàn)有JDK工具可以輕松地對虛擬線程進(jìn)行故障排除、調(diào)試和分析；

簡而言之，現(xiàn)在我們可以輕松地創(chuàng)建一個輕量級的虛擬線程，實現(xiàn)簡單性，同時充分發(fā)揮硬件性能。

以下是一個簡單的示例代碼：

try?(var?executor?=?Executors.newVirtualThreadPerTaskExecutor())?{
????IntStream.range(0,?10000).forEach(i?->?{
????????executor.submit(()?->?{
????????????Thread.sleep(Duration.ofSeconds(1));
????????????return?i;
????????});
????});
}??//?executor.close()?is?called?implicitly,?and?waits

輕量級線程,它承諾大大減少編寫、維護(hù)和觀察高吞吐量并發(fā)應(yīng)用程序的工作量。該計劃的目標(biāo)包括使按線程請求風(fēng)格編寫的服務(wù)器應(yīng)用程序能夠在接近最佳硬件利用率的情況下擴(kuò)展,使使用lang.Thread API的現(xiàn)有代碼通過最小更改采用虛擬線程,并使用當(dāng)前JDK工具輕松調(diào)試和分析虛擬線程。虛擬線程在JDK 20和JDK 19中進(jìn)行了預(yù)覽,將在JDK 21中最終確定。在JDK 21中,虛擬線程現(xiàn)在始終支持線程本地變量,并使創(chuàng)建不具有這些變量的虛擬線程成為不可能。保證對線程本地變量的支持可以確保更多現(xiàn)有庫可以不變地與虛擬線程一起使用,并幫助將面向任務(wù)的代碼遷移到使用虛擬線程。

2.14 序列集合SequencedCollection Interface（順序集合 接口）

兄弟們，作為一個天天CRUD，CPU跑不滿20%的程序員， 相比上面的虛擬線程，這次關(guān)于集合類接口的更新我感覺更實在一些

JDK21中我們常用的Set、List、Deque與Map集合類分別繼承實現(xiàn)了SequencedCollection、 SequencedMap 接口，為我們執(zhí)行一些順序性操作比如獲取頭尾值提供了各類接口方法

繼承關(guān)系如下圖所示：

接口定義如下

interface?SequencedCollection<E>?extends?Collection<E>?{
????//?new?method
????SequencedCollection<E>?reversed();
????//?methods?promoted?from?Deque
????void?addFirst(E);
????void?addLast(E);
????E?getFirst();
????E?getLast();
????E?removeFirst();
????E?removeLast();
}
interface?SequencedSet<E>?extends?Set<E>,?SequencedCollection<E>?{
????SequencedSet<E>?reversed();????//?covariant?override
}
interface?SequencedMap<K,V>?extends?Map<K,V>?{
????//?new?methods
????SequencedMap<K,V>?reversed();
????SequencedSet<K>?sequencedKeySet();
????SequencedCollection<V>?sequencedValues();
????SequencedSet<Entry<K,V>>?sequencedEntrySet();
????V?putFirst(K,?V);
????V?putLast(K,?V);
????//?methods?promoted?from?NavigableMap
????Entry<K,?V>?firstEntry();
????Entry<K,?V>?lastEntry();
????Entry<K,?V>?pollFirstEntry();
????Entry<K,?V>?pollLastEntry();
}

2.15 字符串模板

JDK 21中的預(yù)覽功能,它通過將字面文本與嵌入式表達(dá)式和處理器結(jié)合來補充Java的現(xiàn)有字符串文本塊,以產(chǎn)生特定結(jié)果。這種語言特性和API旨在通過使動態(tài)計算的值易于表示字符串來簡化Java程序的編寫。它有望增強(qiáng)表達(dá)式的可讀性,提高程序安全性,保持靈活性,并簡化使用以非Java語言編寫的字符串的API。啟用從字面文本和嵌入式表達(dá)式組合派生非字符串表達(dá)式的開發(fā)也是一個目標(biāo)。

與這些JDK增強(qiáng)提案分開,據(jù)Oracle的Java團(tuán)隊稱,JDK 21將更改JDK在Windows上為網(wǎng)絡(luò)接口分配名稱的方式。執(zhí)行網(wǎng)絡(luò)多播或使用java.net.NetworkInterface API的應(yīng)用程序維護(hù)人員應(yīng)注意此更改。

JDK歷史上為Windows上的網(wǎng)絡(luò)接口合成名稱。這已更改為使用Windows操作系統(tǒng)分配的名稱。此更改可能會影響使用NetworkInterface.GetbyName(String name)方法查找網(wǎng)絡(luò)接口的代碼。JDK 21還將在JDK飛行記錄器中進(jìn)行關(guān)鍵更改,包括使從命令行分析飛行記錄更加容易。

總結(jié)

以上是我認(rèn)為JDK21版本中一些有價值的更新的總結(jié)。如果你希望進(jìn)一步了解，請自行查看官網(wǎng)https://openjdk.org/projects/jdk/21/，并在發(fā)布后進(jìn)行實際驗證。

近年來Java受到其他各種語言的沖擊，給人一種跌落神壇的感覺。因此，我想看看這次的更新是否能給Java帶來一些活力。當(dāng)前Java語言的下降趨勢也可以說是國內(nèi)IT行業(yè)興衰起伏的一個縮影。當(dāng)然，作為一個提供生產(chǎn)力的編程語言，整個建立在Java周邊的完整、穩(wěn)定、強(qiáng)大的生態(tài)系統(tǒng)仍然在適當(dāng)領(lǐng)域發(fā)揮著重要作用，這是短時間內(nèi)無法改變的。但如果你指望靠它干到退休，恐怕連那些收了你學(xué)費的培訓(xùn)機(jī)構(gòu)也不敢這樣承諾。程序員的職業(yè)壽命從來不是某種編程語言決定的。