Java16正式發(fā)布版本的新特性

Java16累計修復了1897個問題，其中，有1397個由甲骨文工作人員完成，還有500個由個人開發(fā)人員和其他組織機構的開發(fā)人員貢獻，包括ARM、SAP、RedHat和騰訊以及微軟、英特爾、華為等。而一些小型組織也貢獻了Java16中3％的修復，比如AmpereComputing、Bellsoft、DataDog、Microdoc和獨立開發(fā)人員。

伴隨著數(shù)千個性能、穩(wěn)定性和安全性更新，Java16為用戶提供了十七項主要的增強/更改（稱為JDK增強提案——JEP），包括三個孵化器模塊和一個預覽特性。

Java16隨附的17個JEP分為六個不同類別：

新語言特性

JEP394，適用于instanceof的模式匹配

模式匹配（PatternMatching）最早在Java14中作為預覽特性引入，在Java15中還是預覽特性。模式匹配通過對instacneof運算符進行模式匹配來增強Java編程語言。

模式匹配使程序中的通用邏輯（即從對象中有條件地提取組件）得以更簡潔、更安全地表示。

JEP395，記錄

記錄（Records）在Java14和Java15中作為預覽特性引入。它提供了一種緊湊的語法來聲明類，這些類是淺層不可變數(shù)據(jù)的透明持有者。這將大大簡化這些類，并提高代碼的可讀性和可維護性。

JVM改進

JEP376，ZGC并發(fā)線程處理

JEP376將ZGC線程棧處理從安全點轉(zhuǎn)移到一個并發(fā)階段，甚至在大堆上也允許在毫秒內(nèi)暫停GC安全點。消除ZGC垃圾收集器中后面一個延遲源可以極大地提高應用程序的性能和效率。

JEP387，彈性元空間

此特性可將未使用的HotSpot類元數(shù)據(jù)（即元空間，metaspace）內(nèi)存更快速地返回到操作系統(tǒng)，從而減少元空間的占用空間。具有大量類加載和卸載活動的應用程序可能會占用大量未使用的空間。新方案將元空間內(nèi)存按較小的塊分配，它將未使用的元空間內(nèi)存返回給操作系統(tǒng)來提高彈性，從而提高應用程序性能并降低內(nèi)存占用。

新工具和庫

JEP380，Unix-Domain套接字通道

Unix-domain套接字一直是大多數(shù)Unix平臺的一個特性，現(xiàn)在在Windows10和WindowsServer2019也提供了支持。此特性為java.nio.channels包的套接字通道和服務器套接字通道API添加了Unix-domain（AF_UNIX）套接字支持。它擴展了繼承的通道機制以支持Unix-domain套接字通道和服務器套接字通道。Unix-domain套接字用于同一主機上的進程間通信（IPC）。它們在很大程度上類似于TCP/IP，區(qū)別在于套接字是通過文件系統(tǒng)路徑名而不是Internet協(xié)議（IP）地址和端口號尋址的。對于本地進程間通信，Unix-domain套接字比TCP/IP環(huán)回連接更安全、更有效。

JEP392，打包工具

此特性最初是作為Java14中的一個孵化器模塊引入的，該工具允許打包自包含的Java應用程序。它支持原生打包格式，為最終用戶提供自然的安裝體驗，這些格式包括Windows上的msi和exe、macOS上的pkg和dmg，還有Linux上的deb和rpm。它還允許在打包時指定啟動時參數(shù)，并且可以從命令行直接調(diào)用，也可以通過ToolProviderAPI以編程方式調(diào)用。注意jpackage模塊名稱從jdk.incubator.jpackage更改為jdk.jpackage。這將改善最終用戶在安裝應用程序時的體驗，并簡化了“應用商店”模型的部署。

為未來做好準備

JEP390，對基于值的類發(fā)出警告

此特性將原始包裝器類（java.lang.Integer、java.lang.Double等）指定為基于值的（類似于java.util.Optional和java.time.LocalDateTime），并在其構造器中添加forRemoval（自JDK9開始被棄用），這樣會提示新的警告。在Java平臺中嘗試在任何基于值的類的實例上進行不正確的同步時，它會發(fā)出警告。

許多流行的開源項目已經(jīng)在其源中刪除了包裝構造器調(diào)用來響應Java9的棄用警告，并且鑒于“棄用移除”警告的緊迫性，我們可以期望更多開源項目跟上這一步伐。

JEP396，默認強封裝JDK內(nèi)部元素

此特性會默認強封裝JDK的所有內(nèi)部元素，但關鍵內(nèi)部API（例如sun.misc.Unsafe）除外。默認情況下，使用早期版本成功編譯的訪問JDK內(nèi)部API的代碼可能不再起作用。鼓勵開發(fā)人員從使用內(nèi)部元素遷移到使用標準API的方法上，以便他們及其用戶都可以無縫升級到將來的Java版本。強封裝由JDK9的啟動器選項–illegal-access控制，到JDK15默認改為warning，從JDK16開始默認為deny。（目前）仍然可以使用單個命令行選項放寬對所有軟件包的封裝，將來只有使用–add-opens打開特定的軟件包才行。

孵化器和預覽特性

JEP338，向量API（孵化器）

該孵化器API提供了一個API的初始迭代以表達一些向量計算，這些計算在運行時可靠地編譯為支持的CPU架構上的比較佳向量硬件指令，從而獲得優(yōu)于同等標量計算的性能，充分利用單指令多數(shù)據(jù)（SIMD）技術（大多數(shù)現(xiàn)代CPU上都可以使用的一種指令）。盡管HotSpot支持自動向量化，但是可轉(zhuǎn)換的標量操作集有限且易受代碼更改的影響。該API將使開發(fā)人員能夠輕松地用Java編寫可移植的高性能向量算法。

JEP389，外部鏈接器API（孵化器）

該孵化器API提供了靜態(tài)類型、純Java訪問原生代碼的特性，該API將大大簡化綁定原生庫的原本復雜且容易出錯的過程。Java1.1就已通過Java原生接口（JNI）支持了原生方法調(diào)用，但并不好用。Java開發(fā)人員應該能夠為特定任務綁定特定的原生庫。它還提供了外來函數(shù)支持，而無需任何中間的JNI粘合代碼。

JEP393，外部存儲器訪問API（第3個孵化器）

在Java14和Java15中作為孵化器API引入的這個API使Java程序能夠安全有效地對各種外部存儲器（例如本機存儲器、持久性存儲器、托管堆存儲器等）進行操作。它提供了外部鏈接器API的基礎。

JEP397，密封類（第二預覽）

這個預覽特性可以限制哪些類或接口可以擴展或?qū)崿F(xiàn)它們；它允許類或接口的作者控制負責實現(xiàn)它的代碼；它還提供了比訪問修飾符更具聲明性的方式來限制對超類的使用。它還通過對模式進行詳盡的分析來支持模式匹配的未來發(fā)展。

提升OpenJDK開發(fā)人員的生產(chǎn)力

其余更改對Java開發(fā)人員（使用Java編寫代碼和運行應用程序的人員）不會直接可見，而只對Java開發(fā)人員（參與OpenJDK開發(fā)的人員）可見。

JEP347，啟用C++14語言特性（在JDK源代碼中）

它允許在JDKC++源代碼中使用C++14語言特性，并提供在HotSpot代碼中可以使用哪些特性的具體指導。在JDK15中，JDK中C++代碼使用的語言特性僅限于C++98/03語言標準。它要求更新各種平臺編譯器的較低可接受版本

JEP357，從Mercurial遷移到Git；JEP369，遷移到GitHub

這些JEP將OpenJDK社區(qū)的源代碼存儲庫從Mercurial（hg）遷移到Git，并將它們托管在GitHub上以供JDK11及更高版本使用，其中包括將jcheck、webrev和defpath工具等工具更新到Git。Git減小了元數(shù)據(jù)的大?。s1/4），可節(jié)省本地磁盤空間并減少克隆時間。與Mercurial相比，現(xiàn)代工具鏈可以更好地與Git集成。

JEP386，AlpineLinux移植；JEP388，Windows/AArch64移植

這些JEP的重點不是移植工作本身，而是將它們集成到JDK主線存儲庫中；JEP386將JDK移植到AlpineLinux和其他使用musl作為x64上主要C庫的發(fā)行版上。此外，JEP388將JDK移植到WindowsAArch64（ARM64）。