Java 21 / JDK 21 已正式 GA，此版本是繼 JDK 17 后的長期支持版本 (LTS)，Oracle 將為其提供至少八年的技術(shù)支持和更新。根據(jù) Oracle 免費(fèi)條款和條件 (NFTC)，JDK 21 二進(jìn)制文件可在生產(chǎn)中免費(fèi)使用，也可免費(fèi)再分發(fā)。

JDK 21 將根據(jù) NFTC 接受更新，直至 2026 年 9 月，即下一個(gè) LTS 發(fā)布一年后。JDK 21 的后續(xù)更新將根據(jù) Java SE OTN License (OTN) 授權(quán)，超出 OTN License 有限免費(fèi)授權(quán)范圍的生產(chǎn)使用將需要付費(fèi)。

Java SE Development Kit 21提供了數(shù)以千計(jì)的性能、穩(wěn)定性和安全性改進(jìn)，包括平臺(tái)增強(qiáng)功能，可幫助開發(fā)人員提高工作效率并推動(dòng)整個(gè)組織的創(chuàng)新和增長。新版本在語言特點(diǎn)、庫、性能、管理權(quán)等多個(gè)方面進(jìn)行主要更新和增強(qiáng)，全新的功能帶來絕佳的使用體驗(yàn)！

主要新功能

1. 語言特點(diǎn)

? 記錄模式

使用記錄模式增強(qiáng) Java 編程語言以解構(gòu)記錄值。可以嵌套記錄模式和類型模式，以實(shí)現(xiàn)功能強(qiáng)大、聲明性和可組合形式的數(shù)據(jù)導(dǎo)航和處理。

? 開關(guān)模式匹配

通過表達(dá)式和語句的模式匹配來增強(qiáng) Java 編程語言。擴(kuò)展模式匹配允許針對多個(gè)模式測試表達(dá)式，每個(gè)模式都有一個(gè)特定的操作，以便可以簡潔安全地表達(dá)復(fù)雜的面向數(shù)據(jù)的查詢。

1.1 語言功能預(yù)覽

? 字符串模板（預(yù)覽版）

使用字符串模板增強(qiáng) Java 編程語言。字符串模板通過將文字文本與嵌入式表達(dá)式和模板處理器耦合來補(bǔ)充 Java 現(xiàn)有的字符串文字和文本塊，以產(chǎn)生專門的結(jié)果。這是一個(gè)預(yù)覽語言功能和 API。

? 未命名模式和變量（預(yù)覽版）

使用未命名的模式（與記錄組件匹配而不說明組件的名稱或類型）和未命名變量（可以初始化但不使用）來增強(qiáng) Java 語言。兩者都由下劃線字符 表示。這是一項(xiàng)預(yù)覽語言功能。_

? 未命名類和實(shí)例主方法（預(yù)覽版）

改進(jìn) Java 語言，以便學(xué)生可以編寫他們的第一個(gè)程序，而無需了解為大型程序設(shè)計(jì)的語言功能。學(xué)生遠(yuǎn)非使用單獨(dú)的Java方言，而是可以為單類程序編寫簡化的聲明，然后隨著技能的增長無縫擴(kuò)展他們的程序以使用更高級(jí)的功能。這是一項(xiàng)預(yù)覽語言功能。

2. 庫改進(jìn)

? 虛擬線程

將虛擬線程引入 Java 平臺(tái)。虛擬線程是輕量級(jí)線程，可顯著減少編寫、維護(hù)和觀察高吞吐量并發(fā)應(yīng)用程序的工作量。

? 排序集合

引入新接口來表示具有定義的遭遇順序的集合。每個(gè)這樣的集合都有一個(gè)明確定義的第一個(gè)元素、第二個(gè)元素，依此類推，直到最后一個(gè)元素。它還提供統(tǒng)一的 API，用于訪問其第一個(gè)和最后一個(gè)元素，以及以相反的順序處理其元素。

“生活只能倒著理解;但它必須向前生活。

— 克爾凱郭爾

? 密鑰封裝機(jī)制接口

介紹密鑰封裝機(jī)制 （KEM） 的 API，這是一種使用公鑰加密保護(hù)對稱密鑰的加密技術(shù)。

2.1 庫改進(jìn)預(yù)覽和孵化器

? 外部函數(shù)和內(nèi)存 API（第三預(yù)覽版）

引入一個(gè) API，通過該 API，Java 程序可以與 Java 運(yùn)行時(shí)之外的代碼和數(shù)據(jù)進(jìn)行互操作。通過有效地調(diào)用外部函數(shù)（即JVM外部的代碼）和安全地訪問外部內(nèi)存（即不由JVM管理的內(nèi)存），API使Java程序能夠調(diào)用本機(jī)庫并處理本機(jī)數(shù)據(jù)，而不會(huì)像JNI那樣脆弱和危險(xiǎn)。這是一個(gè)預(yù)覽版 API。

? 結(jié)構(gòu)化并發(fā)（預(yù)覽版）

通過引入結(jié)構(gòu)化并發(fā) API 來簡化并發(fā)編程。結(jié)構(gòu)化并發(fā)將在不同線程中運(yùn)行的相關(guān)任務(wù)組視為單個(gè)工作單元，從而簡化錯(cuò)誤處理和取消，提高可靠性并增強(qiáng)可觀測性。這是一個(gè)預(yù)覽版 API。

? 作用域值（預(yù)覽版）

引入作用域值，這些值可以在不使用方法參數(shù)的情況下安全有效地共享到方法。它們優(yōu)先于線程局部變量，尤其是在使用大量虛擬線程時(shí)。這是一個(gè)預(yù)覽版 API。

實(shí)際上，作用域值是一個(gè)隱式方法參數(shù)。“好像”調(diào)用序列中的每個(gè)方法都有一個(gè)額外的、不可見的參數(shù)。沒有一種方法聲明此參數(shù)，只有有權(quán)訪問作用域值對象的方法才能訪問其值（數(shù)據(jù)）。作用域值使通過一系列中間方法將數(shù)據(jù)從調(diào)用方安全地傳遞到遠(yuǎn)方被調(diào)用方成為可能，這些中間方法不聲明數(shù)據(jù)的參數(shù)，并且無法訪問數(shù)據(jù)。

? 載體 API（第六孵化器）

引入一個(gè) API 來表達(dá)矢量計(jì)算，該計(jì)算在運(yùn)行時(shí)可靠地編譯為支持的 CPU 架構(gòu)上的最佳矢量指令，從而實(shí)現(xiàn)優(yōu)于等效標(biāo)量計(jì)算的性能。

3. 性能改進(jìn)

? 代代中關(guān)村

通過擴(kuò)展 Z 垃圾回收器 （ZGC） 來提高應(yīng)用程序性能，以便為年輕對象和舊對象維護(hù)不同的代。這將使ZGC能夠更頻繁地收集年輕物體 - 這些物體往往會(huì)英年早逝。

4. 管理權(quán)

? 準(zhǔn)備禁止代理的動(dòng)態(tài)加載

在將代理動(dòng)態(tài)加載到正在運(yùn)行的 JVM 中時(shí)發(fā)出警告。這些警告旨在讓用戶為將來的版本做好準(zhǔn)備，該版本默認(rèn)不允許動(dòng)態(tài)加載代理，以便在默認(rèn)情況下提高完整性。在啟動(dòng)時(shí)加載代理的功能功能工具不會(huì)導(dǎo)致在任何版本中發(fā)出警告。

詳細(xì)新功能請參考：https://www.oracle.com/java/technologies/javase/21-relnote-issues.html

正式穩(wěn)定功能

JEP 444：虛擬線程

JEP 431：序列集合

JEP 440：記錄模式

JEP 441：switch 模式匹配

JEP 439：分代 ZGC

JEP 449：棄用 Windows 32 位 x86 移植

JEP 451：準(zhǔn)備禁止動(dòng)態(tài)加載代理

JEP 452：密鑰封裝機(jī)制 API

預(yù)覽階段功能

JEP 442：外部函數(shù)和內(nèi)存 API（第三次預(yù)覽）

JEP 446：作用域值（預(yù)覽）

JEP 453：結(jié)構(gòu)化并發(fā)（預(yù)覽）

JEP 430：字符串模板（預(yù)覽）

JEP 443：未命名模式和變量（預(yù)覽）

JEP 445：未命名類和實(shí)例主方法（預(yù)覽）

孵化階段功能

JEP 448：Vector API（孵化器第六階段）

Java SE Development Kit 21安裝教程

1、下載并解壓，如圖所示

2、安裝，安裝目錄

3、安裝完成，根據(jù)提示進(jìn)行后續(xù)設(shè)置

更新日志

Java™ SE 開發(fā)工具包 21.0.7 （JDK 21.0.7）
4月 15， 2025

此更新版本的完整版本字符串為 21.0.7+8（其中“+”表示“內(nèi)部版本”）。 版本號(hào)為 21.0.7。此 JDK 符合 Java SE 規(guī)范 （JSR 396， 2023-09-19） 的版本 21。

IANA TZ 數(shù)據(jù) 2025a
JDK 21.0.7 包含 IANA 時(shí)區(qū)數(shù)據(jù) 2025a，其中包含以下更改：

巴拉圭從 2024 年春季開始采用永久性 -03。
改進(jìn)菲律賓 1991 年之前的數(shù)據(jù)。
Etc/Unknown 現(xiàn)在已保留。

使 JDK 保持最新狀態(tài)

Oracle 建議使用每個(gè)重要補(bǔ)丁更新來更新 JDK。 為了確定某個(gè)版本是否為最新版本，Security Baseline （安全基線） 頁面可以 用于確定哪個(gè)版本是每個(gè)版本系列的最新版本。

包含安全漏洞修復(fù)的關(guān)鍵補(bǔ)丁更新會(huì)提前一年公布 重要補(bǔ)丁更新、安全警報(bào)和公告。 不建議在計(jì)劃下一次關(guān)鍵補(bǔ)丁更新后使用此 JDK（版本 21.0.7） 2025 年 7 月 15 日。

Java 管理服務(wù)可供所有用戶使用，可幫助您在系統(tǒng)中找到易受攻擊的 Java 版本。在 Oracle Cloud 中運(yùn)行的 Java SE 訂戶和客戶可以使用 Java 管理服務(wù)更新 Java 運(yùn)行時(shí)并進(jìn)行進(jìn)一步的安全審查，例如識(shí)別 Java 程序使用的潛在易受攻擊的第三方庫?，F(xiàn)有 Java 管理服務(wù)用戶單擊此處登錄到您的儀表板。Java 管理服務(wù)文檔提供了可供所有人使用的功能列表，以及僅可供客戶使用的功能列表。了解有關(guān)使用 Java 管理服務(wù)監(jiān)控和保護(hù) Java 安裝的更多信息。

新功能

security-libs/javax.crypto：pkcs11
? SunPKCS11 提供程序中的傳統(tǒng)機(jī)制檢查通過服務(wù)類型進(jìn)行了增強(qiáng) （JDK-8293345)
支持解密但不支持加密或簽名驗(yàn)證但不支持簽名的本機(jī) PKCS11 機(jī)制被視為舊版，默認(rèn)情況下處于禁用狀態(tài)。SunPKCS11 提供程序中的傳統(tǒng)機(jī)制檢查通過服務(wù)類型進(jìn)行了增強(qiáng)。例如，在此修復(fù)之前，支持加密、解密和驗(yàn)證但不支持簽名的機(jī)制被視為舊機(jī)制，根本不能使用。修復(fù)此漏洞后，由于支持加密和解密，因此可以使用使用此機(jī)制的相應(yīng) Cipher 服務(wù)。但是，相應(yīng)的 Signature 服務(wù)不是，因?yàn)閮H支持驗(yàn)證。要繞過傳統(tǒng)機(jī)制檢查，請將 PKCS11 提供程序配置屬性“allowLegacy”設(shè)置為 true。默認(rèn)值為 false。請注意，調(diào)用方有責(zé)任確保 legacy 機(jī)制不用于不支持的功能。

其他說明

安全庫/javax.net.ssl
? 不信任由 Camerfirma 根證書錨定并在 2025 年 4 月 15 日之后頒發(fā)的 TLS 服務(wù)器證書 （JDK-8346587)
JDK 將停止信任 2025 年 4 月 15 日之后頒發(fā)并由 Camerfirma 根證書錨定的 TLS 服務(wù)器證書，這與 Google、Mozilla、Apple 和 Microsoft 宣布的類似計(jì)劃一致。

在 2025 年 4 月 15 日或之前頒發(fā)的 TLS 服務(wù)器證書將繼續(xù)受信任，直到過期。在該日期之后頒發(fā)并由下表中的任何證書頒發(fā)機(jī)構(gòu)錨定的證書將被拒絕。

這些限制在 Java 安全套接字?jǐn)U展 （JSSE） API 的 JDK 實(shí)現(xiàn)（提供程序）中強(qiáng)制執(zhí)行。如果服務(wù)器的證書鏈由下表中的任何證書頒發(fā)機(jī)構(gòu)錨定，并且證書是在 2025 年 4 月 15 日之后頒發(fā)的，則不會(huì)協(xié)商 TLS 會(huì)話。SunJSSE

應(yīng)用程序?qū)⑹盏揭粋€(gè)異常，并顯示一條消息，指示信任錨不受信任，例如：

"TLS Server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A.,

SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU"

可以通過從配置文件的 security 屬性中刪除 “CAMERFIRMA_TLS” 來將 JDK 配置為再次信任這些證書。jdk.security.caDistrustPoliciesjava.security

您還可以使用 JDK 中的實(shí)用程序打印出證書鏈的詳細(xì)信息，如下所示：keytool

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

如果鏈中的任何證書由上表中的根 CA 之一頒發(fā)，則輸出中列出了該證書，則需要更新證書或聯(lián)系管理該服務(wù)器的組織。

core-svc/tools
? JarInputStream 將具有多個(gè)清單的已簽名 JAR 視為無符號(hào) （JDK-8337494（未公開））
現(xiàn)在，如果該類在 JAR 文件的前兩個(gè)條目中檢測到第二個(gè)清單，則該類會(huì)將已簽名的 JAR 視為未簽名。如果設(shè)置了系統(tǒng)屬性 ，則會(huì)記錄一條警告消息。JarInputStream"WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned."-Djava.security.debug=jar

熱點(diǎn)/GC
? 并行 GC 在堆完全擴(kuò)展之前引發(fā) OOM （JDK-8328744）)
現(xiàn)有錯(cuò)誤可能阻止了完全使用由 command line flag 分配的 Java 堆。JDK-8328744 已修復(fù)該錯(cuò)誤。作為此修復(fù)的副作用，在使用 Parallel GC 時(shí)，安裝可能會(huì)遇到堆使用量增加的情況。如有必要，客戶應(yīng)調(diào)整最大堆大小。-Xmx

安全庫/javax.security
? 僅 POST OCSP 請求的回退選項(xiàng) （JDK-8328638）)
JDK 17 引入了一項(xiàng)性能改進(jìn)，使 OCSP 客戶端可以無條件地對小請求使用 GET 請求，而對其他所有請求執(zhí)行 POST 請求。RFC 5019 和 RFC 6960 明確允許和推薦這樣做。但是，我們已經(jīng)看到 OCSP 響應(yīng)程序盡管有 RFC 要求，但無法很好地處理 GET 請求。

此版本引入了一個(gè)新的 JDK 系統(tǒng)屬性，以允許客戶端回退到僅 POST 行為。這將通過使用 .這修改了引入 GET OCSP 請求的原始更改 （JDK-8179503）。默認(rèn)行為不會(huì)更改;該選項(xiàng)默認(rèn)為 。將選項(xiàng)設(shè)置為禁用 GET OCSP 請求。除 （不區(qū)分大小寫） 以外的任何值都默認(rèn)為 。-Dcom.sun.security.ocsp.useget={false,true}truefalsefalsetrue

此選項(xiàng)是非標(biāo)準(zhǔn)的，一旦升級(jí)了有問題的 OCSP 響應(yīng)程序，此選項(xiàng)可能會(huì)消失。

Bug 修復(fù)

此版本還包含 Oracle 關(guān)鍵補(bǔ)丁更新中描述的安全漏洞修復(fù)程序。

? 21.0.7 中修復(fù)的問題：
#    JBS 公司    組件/子組件    總結(jié)
1    型號(hào)： JDK-8312518    客戶端庫/java.awt    [macos13] setFullScreenWindow（）在macOS 13及以上版本上顯示黑屏
2    JDK-8335468    客戶端庫/java.awt    [X澳大利亞]調(diào)用 java.awt.Robot.getPixelColor 時(shí) JavaFX 掛起
3    JDK-8283214    client-libs/javax.accessibility    [macOS 的]屏幕放大鏡不顯示 JComboBox 的放大文本
4    JDK-8339728    client-libs/javax.accessibility    [輔助功能，Windows，JAWS]AccessBridge 類的 getKeyChar 方法存在 bug
5    JDK-8332866    客戶端庫/javax.imageio    啟用MEM_STATS時(shí) ImageIO JPEG 解碼崩潰
6    JDK-8347911    客戶端庫/javax.imageio    限制膨脹文本塊的長度
7    型號(hào)： JDK-8332431    client-libs/javax.swing 中    SwingSet2 的 JTable 中的 NullPointerException
8    型號(hào)： JDK-8340824    熱點(diǎn)/編譯器    C2：類型接口的內(nèi)存未被 hashcons（） 回收
9    JDK-8337660    熱點(diǎn)/編譯器    C2：只有 BoxLock 節(jié)點(diǎn)的基本塊被錯(cuò)誤地視為空
10    型號(hào)： JDK-8340313    熱點(diǎn)/編譯器    C1 修補(bǔ)后，由于 nmethod 中的無效 oop 而崩潰
11    型號(hào)： JDK-8331090    熱點(diǎn)/編譯器    在取消規(guī)范化 CMoves 之前運(yùn)行 Ideal_minmax
12    JDK-8324655    熱點(diǎn)/編譯器    識(shí)別使用 if 語句創(chuàng)建的整數(shù)最小和最大模式
13    JDK-8338100    熱點(diǎn)/編譯器    C2：assert（！n_loop->is_member（get_loop（lca））） 失?。嚎丶坏梅祷氐窖h(huán)中
14    JDK-8322957    熱點(diǎn)/GC    分代 ZGC：重定位選擇必須加入 STS
15    JDK-8170817    熱點(diǎn)/GC    G1：從 unsafe_max_tlab_alloc 返回 MinTLABSize 會(huì)導(dǎo)致 TLAB 抖動(dòng)
16    JDK-8328168    熱點(diǎn)/GC    Epsilon：分配大于未提交堆大小的對象時(shí)過早的 OOM
17    JDK-8328166    熱點(diǎn)/GC    Epsilon：'EpsilonHeap：：allocate_work' 錯(cuò)誤地將參數(shù) 'size' 誤用為以字節(jié)為單位的大小
18    型號(hào)： JDK-8315031    熱點(diǎn)/GC    YoungPLABSize 和 OldPLABSize 未按 ObjectAlignmentInBytes 對齊
19    JDK-8329570    熱點(diǎn)/GC    G1：驗(yàn)證中的 is_obj_dead_cond 調(diào)用過多
20    JDK-8329223    熱點(diǎn)/GC    Parallel：并行 GC 調(diào)整堆大小，即使 -Xms = -Xmx
21    型號(hào)： JDK-8330981    熱點(diǎn)/GC    ZGC：不應(yīng)在終結(jié)器圖中對字符串進(jìn)行重復(fù)數(shù)據(jù)刪除
22    型號(hào)： JDK-8330275    熱點(diǎn)/GC    XMark：：follow_array 崩潰
23    JDK-8329088    熱點(diǎn)/GC    具有并發(fā) GC 堆棧迭代的堆棧塊解凍爭用
24    型號(hào)： JDK-8329109    熱點(diǎn)/GC    Threads：:p rint_on（） 嘗試打印已終止的 GC 線程的 CPU 時(shí)間
25    JDK-8325937    熱點(diǎn)/運(yùn)行時(shí)    runtime/handshake/HandshakeDirectTest.java 導(dǎo)致 AArch64 上出現(xiàn)“monitor end should be strictly below the frame pointer”斷言失敗
26    型號(hào)： JDK-8344145    熱點(diǎn)/測試    刪除任務(wù)定義中的 windows_x64_1803_or_later 及其用法
27    JDK-8335288    security-libs/javax.crypto：pkcs11    SunPKCS11 初始化將在不支持的機(jī)制上調(diào)用 C_GetMechanismInfo
28    型號(hào)： JDK-8331959    security-libs/javax.crypto：pkcs11    將 PKCS#11 加密令牌接口更新到 v3.1
29    型號(hào)： JDK-8331958    安全庫/javax.smartcardio    將適用于 Suse Linux 的 PC/SC Lite 更新到 2.3.0