Java16是一個重要的特性發布，它為JAVA帶來了許多JVM特定的更改和語言特定的更改。它遵循了自JavaJava10以來引入的Java發布步調，并于2021年3月發布，僅在Java15發布后的六個月內發布。

Java 16是一個非LTS版本。

338:	Vector API (Incubator)?矢量API（孵化）
347:	Enable C++14 Language Features?啟用C++14語言功能
357:	Migrate from Mercurial to Git?從Mercurial遷移到Git
369:	Migrate to GitHub?遷移到GitHub
376:	ZGC: Concurrent Thread-Stack Processing?ZGC：并發線程堆棧處理
380:	Unix-Domain Socket Channels?Unix域套接字通道
386:	Alpine Linux Port?Alpine Linux端口
387:	Elastic Metaspace?彈性元空間
388:	Windows/AArch64 Port?Windows/AArch64 Port
389:	Foreign Linker API (Incubator)?外部鏈接商API（孵化）
390:	Warnings for Value-Based Classes?基于值的類的警告
392:	Packaging Tool?打包工具
393:	Foreign-Memory Access API (Third Incubator)?外部內存訪問API（第三次孵化）
394:	Pattern Matching for instanceof?增強instanceof
395:	Records?新增Record類
396:	Strongly Encapsulate JDK Internals by Default?默認情況下嚴格封裝JDK內部
397:	Sealed Classes (Second Preview)?密封類（第二次預覽）

JEP 338: Vector API (Incubator)

詳情參閱java16學習筆記-Vector API

JEP 347: Enable C++14 Language Features

允許在JDK C++源代碼中使用C++14語言功能，并就哪些功能可以在HotSpot代碼中使用給出具體指導。

JEP 357: Migrate from Mercurial to Git

將OpenJDK社區的源代碼庫從Mercurial（hg）遷移到Git

JEP 369: Migrate to GitHub

在GitHub上托管OpenJDK社區的Git存儲庫。結合JEP 357Migrate from Mercurial to Git，這將把所有單一存儲庫OpenJDK項目遷移到GitHub，包括JDK功能版本和JDK 11及更高版本的更新版本。

JEP 376: ZGC: Concurrent Thread-Stack Processing

將ZGC線程堆棧處理從安全點轉移到并發階段。

Z垃圾收集器目標是解決JVM中的GC暫停和可擴展性問題。目前我們已經將所有隨堆大小和元空間大小而擴展的GC操作，從安全點操作轉移到并發階段。這些包括標記、重定位、引用處理、類卸載和大多數根處理。
在GC安全點中仍然完成的唯一活動是根處理的一個子集和有時間限制的標記終止操作。根包括Java線程堆棧和各種其他線程根。這些根是有問題的，因為它們會隨著線程的數量而擴展。大型機器上有許多線程，根處理成為一個問題。
為了超越我們今天所擁有的，并滿足在GC安全點內花費的時間不超過一毫秒的期望，即使在大型機器上，我們也必須將每個線程的處理（包括堆棧掃描）轉移到并發階段。
在這項工作之后，ZGC安全點操作內部基本上不會做任何有意義的事情。
作為該項目的一部分構建的基礎設施最終可能會被其他項目（如Loom和JFR）使用，以統一延遲堆棧處理。

JEP 380: Unix-Domain Socket Channels

對于本地，過程間通信，UNIX域插座比TCP/IP環回連接更安全，更有效。

• UNIX域插座嚴格用于同一系統上的過程之間的通信。不打算接受遠程連接的應用程序可以通過使用Unix-Domain插座來提高安全性。

• Unix域插座受到強制執行的基于文件系統的訪問控件的操作系統進一步保護。

• 與TCP/IP環回連接相比，Unix-Domain插座具有更快的設置時間和更高的數據吞吐量。

• 對于容器環境的TCP/IP套件，Unix-Domain插座可能是更好的解決方案，在該容器環境中，需要同一系統上的容器之間的通信。這可以使用位于共享量的插座來實現。

Unix-Domain插座長期以來一直是大多數UNIX平臺的功能，現在在Windows 10和Windows Server 2019中得到支持。

為了支持Unix-Domain插座通道，我們將添加以下API元素：

• 一個新的插座地址類java.net.UnixDomainSocketAddress；

• UNIX現有枚舉的恒定值java.net.StandardProtocolFamily；

• 新的open工廠方法SocketChannel，ServerSocketChannel指定協議家族

• 更新到?SocketChannel規格ServerSocketChannel，以指定通向UNIX域插座行為的渠道。

JEP 386: Alpine Linux Port

將JDK移至Alpine Linux，以及其他使用MUSL作為主要C庫的Linux發行版，都可以在X64和AARCH64架構上。

JEP 387: Elastic Metaspace

更及時地將未使用的HotSpot類元數據（即元空間）內存還給操作系統，減少元空間的占用，并簡化元空間代碼，以降低維護成本。

JEP 388: Windows/AArch64 Port

將 JDK 移植到 Windows/AArch64。

JEP 389: Foreign Linker API (Incubator)

引入一個 API，提供對本機代碼的靜態類型、純 Java 訪問。此 API 與外部內存 API （JEP 393） 一起，將大大簡化綁定到本機庫的容易出錯的過程。

詳情可以查看文章??Foreign-Memory Access API外部內存API -CSDN博客

JEP 390: Warnings for Value-Based Classes

將原始包裝器類指定為基于值的，并棄用其 構造函數，提示新的棄用警告。 提供有關在 Java 平臺中任何基于值的類。

對于用構造函數創建包裝類的java語句例如：Double d = new Double(Math.random())

java8會給出建議

java9-java15

?java16代碼給出警告（飄紅），但是可以運行，

JEP 392: Packaging Tool

提供用于打包獨立 Java 應用程序的工具。jpackage

該工具由?JEP 343?作為孵化工具引入 JDK 14。在 JDK 15 中，它仍然是一個孵化工具，以便有時間獲得額外的反饋。現在，它已準備好從孵化提升為生產就緒功能。由于此轉換，模塊的名稱將從 更改為 。jpackagejpackagejdk.incubator.jpackagejdk.jpackage

相對于 JEP 343 的唯一實質性變化是，我們將該選項替換為更通用的選項，如下：--bind-services--jlink-options

基本用法

$ jpackage --name myapp --input lib --main-jar main.jar

如果所打包文件沒有Main-Class屬性，則必須指定主類

$ jpackage --name myapp --input lib --main-jar main.jar \--main-class myapp.Main

模塊化

$ jpackage --name myapp  --module-path --input lib --main-jar main.jar \--main-class myapp.Main

JEP 393: Foreign-Memory Access API (Third Incubator)

引入一個 API，允許 Java 程序安全高效地訪問 Java 堆之外的外部內存。

?詳情可以查看文章??Foreign-Memory Access API外部內存API -CSDN博客

JEP 394: Pattern Matching for instanceof

通過運算符的模式匹配來增強 Java 編程語言。模式匹配允許程序中的通用邏輯，即條件提取 對象中的組件，以更簡潔、更安全地表達。instanceof

詳情可以查看文章?java14學習筆記-part1-CSDN博客

JEP 395: Records

使用Records增強 Java 編程語言 充當不可變數據的透明載體。

記錄由?JEP 359?提出，并在?JDK 14?中作為預覽功能提供。

為了響應反饋，JEP 384?對設計進行了改進，并在?JDK 15?中作為 預覽功能。第二次預覽的改進如下：

• 在第一個預覽版中，規范構造函數需要為 . 在第二個預覽中，如果規范構造函數是 隱式聲明，則其訪問修飾符與 record 類相同;如果 規范構造函數被顯式聲明，然后它的訪問修飾符必須提供 至少與 Record 類一樣多的訪問權限。public

• 注釋的含義被擴展為包括 注釋方法是顯式聲明的訪問器方法的情況 記錄組件。@Override

• 為了強制執行緊湊構造函數的預期用途，它變成了編譯時 error 分配給構造函數正文中的任何實例字段。

• 能夠聲明本地記錄類、本地枚舉類和本地接口 被介紹。

本 JEP 建議在 JDK 16 中完成該功能，并進行以下改進：

• 放寬長期以來的限制，即內部階級 不能聲明顯式或隱式靜態的成員。這將成為合法的 特別是，將允許內部類聲明作為記錄類的成員。

根據進一步的反饋，可能會進行其他改進。

詳情可以查看文章??java14學習筆記-part1-CSDN博客

JEP 396: Strongly Encapsulate JDK Internals by Default

默認情況下，強封裝 JDK 的所有內部元素，但 用于關鍵的內部 API，例如 .允許結束 用戶選擇寬松的強封裝，即一直 自 JDK 9 以來的默認值。sun.misc.Unsafe

持續提升 JDK 的安全性和可維護性

鼓勵開發者從使用內部元素遷移到 標準 API，以便他們和他們的用戶都可以在沒有 對未來的 Java 版本大驚小怪。

JEP 397: Sealed Classes (Second Preview)

使用密封的類和接口增強 Java 編程語言。密封的類和接口限制了哪些其他類或接口可以擴展或實現它們。這是 JDK 16 中的預覽語言功能。

密封類是由?JEP 360?提出的，并且在?JDK 15?中作為預覽功能交付。

本 JEP 建議在 JDK 16 中重新預覽該功能，并進行以下改進：

• 指定上下文關鍵字的概念，取代先前的概念JLS 中的受限標識符和受限關鍵字。引入字符序列 、 和作為上下文 關鍵字。sealednon-sealedpermits

• 與匿名類和 lambda 表達式一樣，局部類可能不是密封類的子類，在確定隱式聲明的允許類或接口的子類時。sealedsealed

• 增強縮小引用轉換，以執行更嚴格的檢查相對于密封類型層次結構的轉換。

詳情可以查看文章?java15學習筆記-密封類-CSDN博客