Java開發(fā)工具包（JDK）26是Java標(biāo)準(zhǔn)版的計(jì)劃更新，預(yù)定于2026年3月17日發(fā)布，目前已進(jìn)入初始階段的Bug修復(fù)階段，功能特性已凍結(jié)。以下10個(gè)功能正式面向JDK 26：模式、instanceof和switch中原始類型的第四次預(yù)覽，提前時(shí)對(duì)象緩存，Vector API的第十一次孵化，惰性常量和密碼學(xué)對(duì)象PEM編碼的第二次預(yù)覽，結(jié)構(gòu)化并發(fā)的第六次預(yù)覽，關(guān)于使用深度反射修改final字段的警告，通過減少G1垃圾收集器中的同步來提高吞吐量，客戶端API的HTTP/3支持，以及移除Java Applet API。

作為Java的短期發(fā)布版本，JDK 26由六個(gè)月的Premier級(jí)支持提供支持，它繼承了9月16日發(fā)布的JDK 25，后者是一個(gè)長(zhǎng)期支持（LTS）版本，由數(shù)年的Premier級(jí)支持提供支持。JDK 26的早期訪問構(gòu)建版本可在https://jdk.java.net/26/獲取。

最新添加的功能是模式、instanceof和switch中的原始類型，旨在通過允許在所有模式上下文中使用原始類型來增強(qiáng)模式匹配，并擴(kuò)展instanceof和switch以適用于所有原始類型?，F(xiàn)在進(jìn)入第四次預(yù)覽，該功能此前已在JDK 23、JDK 24和JDK 25中進(jìn)行過預(yù)覽。目標(biāo)包括允許對(duì)所有類型使用類型模式來實(shí)現(xiàn)統(tǒng)一的數(shù)據(jù)探索，將類型模式與instanceof對(duì)齊，將instanceof與安全轉(zhuǎn)換對(duì)齊，并允許模式匹配在嵌套和頂級(jí)模式上下文中使用原始類型。第四次預(yù)覽中的更改包括增強(qiáng)無條件準(zhǔn)確性的定義，并在switch構(gòu)造中應(yīng)用更嚴(yán)格的支配檢查。這些更改使編譯器能夠識(shí)別更廣泛的編碼錯(cuò)誤。

通過提前時(shí)對(duì)象緩存，HotSpot JVM將獲得改進(jìn)的啟動(dòng)和預(yù)熱時(shí)間，因此可以與任何垃圾收集器一起使用，包括低延遲的Z垃圾收集器（ZGC）。這將通過使得可以從中性的、與GC無關(guān)的格式將緩存的Java對(duì)象按順序加載到內(nèi)存中來實(shí)現(xiàn)，而不是以GC特定格式直接將它們映射到內(nèi)存中。該功能的目標(biāo)包括允許所有垃圾收集器與Project Leyden引入的AOT（提前時(shí)）緩存平滑協(xié)作，將AOT緩存與GC實(shí)現(xiàn)細(xì)節(jié)分離，并確保使用AOT緩存相對(duì)于以前的版本不會(huì)對(duì)啟動(dòng)時(shí)間產(chǎn)生實(shí)質(zhì)影響。

Vector API的第十一次孵化引入了一個(gè)API來表達(dá)矢量計(jì)算，在運(yùn)行時(shí)可靠地編譯為支持CPU上的最優(yōu)矢量指令。這實(shí)現(xiàn)了優(yōu)于等效標(biāo)量計(jì)算的性能。孵化中的Vector API可追溯到2021年3月到達(dá)的JDK 16。該API旨在清晰簡(jiǎn)潔，與平臺(tái)無關(guān)，在x64和AArch64 CPU上具有可靠的編譯和性能，并提供優(yōu)雅的降級(jí)。Vector API的長(zhǎng)期目標(biāo)是利用Project Valhalla對(duì)Java對(duì)象模型的增強(qiáng)。

JDK 26的議程中還包括惰性常量API的另一次預(yù)覽，該API曾在JDK 25中通過穩(wěn)定值能力進(jìn)行過預(yù)覽。惰性常量是保存不可修改數(shù)據(jù)并被JVM視為真正常量的對(duì)象，使得能夠?qū)崿F(xiàn)與聲明字段為final相同的性能優(yōu)化。惰性常量在初始化時(shí)機(jī)方面提供了更大的靈活性。

PEM編碼的第二次預(yù)覽要求為編碼表示密碼學(xué)密鑰、證書和證書撤銷列表的對(duì)象到PEM傳輸格式，以及從該格式解碼回對(duì)象的API。PEM API在JDK 25中被提議作為預(yù)覽功能。第二次預(yù)覽包含許多更改，例如PEMRecord類現(xiàn)在被命名為PEM，現(xiàn)在包含一個(gè)返回解碼的Base64內(nèi)容的decode()方法。此外，EncryptedPrivateKeyInfo類的encryptKey方法現(xiàn)在被命名為encrypt，現(xiàn)在接受DEREncodable對(duì)象而不是PrivateKey對(duì)象，從而能夠加密KeyPair和PKCS8EncodedKeySpec對(duì)象。

結(jié)構(gòu)化并發(fā)API通過將在不同線程中運(yùn)行的相關(guān)任務(wù)組作為單個(gè)工作單元來簡(jiǎn)化并發(fā)編程，從而簡(jiǎn)化錯(cuò)誤處理和取消，提高可靠性，并增強(qiáng)可觀察性。目標(biāo)包括推廣一種可以消除由取消和關(guān)閉引起的常見風(fēng)險(xiǎn)（如線程泄漏和取消延遲）的并發(fā)編程風(fēng)格，并改善并發(fā)代碼的可觀察性。

關(guān)于使用深度反射修改final字段的新警告旨在為開發(fā)者準(zhǔn)備未來的發(fā)布版本，該版本將通過限制final字段修改來確保默認(rèn)完整性，換句話說，使final真正意味著final，這將使Java程序更安全且可能更快。應(yīng)用程序開發(fā)者可以通過在必要時(shí)選擇性地啟用修改final字段的能力來避免當(dāng)前的警告和未來的限制。

G1 GC提案旨在通過減少應(yīng)用程序線程和GC線程之間所需的同步量來改善使用G1垃圾收集器時(shí)的應(yīng)用程序吞吐量和延遲。目標(biāo)包括減少G1垃圾收集器的同步開銷，減少G1寫屏障的注入代碼大小，并保持G1的整體架構(gòu)，不改變用戶交互。

G1 GC提案指出，盡管G1作為HotSpot JVM的默認(rèn)垃圾收集器，設(shè)計(jì)用于平衡延遲和吞吐量，但實(shí)現(xiàn)這種平衡有時(shí)會(huì)相對(duì)于面向吞吐量的垃圾收集器（如Parallel和Serial收集器）對(duì)應(yīng)用程序性能產(chǎn)生負(fù)面影響：

相對(duì)于Parallel，G1與應(yīng)用程序更多地并發(fā)執(zhí)行其工作，減少了GC暫停的持續(xù)時(shí)間，從而改善了延遲。不可避免地，這意味著應(yīng)用程序線程必須與GC線程共享CPU并與其協(xié)調(diào)。這種同步既降低了吞吐量又增加了延遲。

HTTP/3提案要求允許Java庫(kù)和應(yīng)用程序以最小的代碼更改與HTTP/3服務(wù)器交互。目標(biāo)包括更新HTTP客戶端API以發(fā)送和接收HTTP/3請(qǐng)求和響應(yīng)；只需要對(duì)HTTP客戶端API和Java應(yīng)用程序代碼進(jìn)行輕微更改；以及允許開發(fā)者選擇性地使用HTTP/3，而不是將默認(rèn)協(xié)議版本從HTTP/2更改為HTTP/3。

HTTP/3被認(rèn)為是用于網(wǎng)絡(luò)的HTTP（超文本傳輸協(xié)議）數(shù)據(jù)通信協(xié)議的主要版本。版本3建立在IETF QUIC（快速UDP互聯(lián)網(wǎng)連接）傳輸協(xié)議上，該協(xié)議在其能力中強(qiáng)調(diào)流控制流、低延遲連接建立、網(wǎng)絡(luò)路徑遷移和安全性。

移除現(xiàn)在被認(rèn)為已過時(shí)的Java Applet API也是JDK 26的目標(biāo)。Applet API在2021年的JDK 17中被棄用以進(jìn)行移除。根據(jù)提案，該API已過時(shí)，因?yàn)樽罱腏DK發(fā)布版本和當(dāng)前的網(wǎng)絡(luò)瀏覽器都不支持applet。提案指出，沒有理由保留未使用且不可用的API。

Q&A

Q1：JDK 26什么時(shí)候發(fā)布？它有哪些主要新功能？

A：JDK 26預(yù)定于2026年3月17日發(fā)布，包含10個(gè)主要新功能：原始類型模式匹配的第四次預(yù)覽、提前時(shí)對(duì)象緩存、Vector API第十一次孵化、惰性常量和PEM編碼的第二次預(yù)覽、結(jié)構(gòu)化并發(fā)第六次預(yù)覽、deep reflection警告、G1 GC性能優(yōu)化、HTTP/3支持，以及移除Java Applet API。

Q2：G1垃圾收集器的改進(jìn)能帶來什么好處？

A：G1垃圾收集器的改進(jìn)主要通過減少應(yīng)用程序線程和GC線程之間的同步量來提高應(yīng)用程序吞吐量和降低延遲。改進(jìn)包括減少同步開銷、縮小寫屏障注入代碼大小，同時(shí)保持G1的整體架構(gòu)不變，讓應(yīng)用程序在垃圾收集時(shí)獲得更好的性能表現(xiàn)。

Q3：為什么要移除Java Applet API？

A：Java Applet API在JDK 26中被移除是因?yàn)樗呀?jīng)完全過時(shí)。該API在2021年的JDK 17中就被標(biāo)記為棄用，因?yàn)樽钚碌腏DK版本和現(xiàn)代網(wǎng)絡(luò)瀏覽器都不再支持applet技術(shù)，保留這個(gè)未使用且不可用的API沒有意義。