JDK 16 新特性，正式發(fā)布！程序員：追不上了...
閱讀本文大概需要 8 分鐘。
Java 16 發(fā)布了！
1、通過適應不斷變化的技術格局來保持靈活性，同時維持平臺獨立性。
2、通過保持向后兼容性來保證可靠性。
3、在不犧牲安全性的前提下加速創(chuàng)新來保持優(yōu)勢。
Java 憑借自身不斷提高平臺性能、穩(wěn)定性和安全性的能力，一直是開發(fā)人員中最流行的編程語言。IDC 的最新報告“Java Turns 25”顯示，超過 900 萬名開發(fā)人員（全球專職開發(fā)人員中的 69%）在使用 Java——比其他任何語言都多。
甲骨文還在繼續(xù)探索 Java 的持續(xù)創(chuàng)新之路，并自豪地宣布 Java 16 正式發(fā)布，這也是我們轉向六個月發(fā)布周期后的第七個特性版本。這種可預測水平使開發(fā)人員可以更輕松地管理他們對創(chuàng)新的采用計劃。
上圖顯示了自 Java 8 以來每個版本的特性數(shù)量
Java 16 現(xiàn)在已可用
Java 16，我們攜手同行
與之前的版本類似，我們將繼續(xù)感謝來自 OpenJDK 社區(qū)中眾多個人和組織對 Java 16 所做的貢獻——我們攜手同行，共同構建 Java！
JDK 16 修復比率
JDK 的總體變化率多年來一直保持基本穩(wěn)定，但是在六個月的發(fā)布周期下，可用于生產的創(chuàng)新交付速度已大大提高。
過去，我們每隔幾年在大型主要版本中發(fā)布成千上萬的修復和大約一百個 JDK 增強提案（JEP）；而現(xiàn)在，我們改為更易于管理、更容易預測的六個月周期，在較小的特性版本中提供增強特性。這些更改的范圍從重大特性到小型改進和例行維護、錯誤修復和文檔改進。每個更改都在 JDK 錯誤系統(tǒng) 中用一個問題的一次提交來表示。
在 Java 16 中標記為修復的 1,897 個問題中，有 1,397 個由甲骨文工作人員完成，還有 500 個由個人開發(fā)人員和為其他組織工作的開發(fā)人員貢獻。我們整理了貢獻者所在組織的數(shù)據(jù)，得到了以下組織分布圖：
上圖顯示每個組織貢獻的修復數(shù)量
甲骨文要感謝為 ARM、SAP、RedHat 和騰訊等組織工作的開發(fā)人員所做的杰出貢獻，同時也感謝來自小型組織（如 Ampere Computing、Bellsoft、DataDog、Microdoc 和獨立開發(fā)人員）的貢獻，他們貢獻了 Java 16 中 3％的修復。
我們同樣感謝許多審查提案更改的經(jīng)驗豐富的開發(fā)人員、嘗試采用早期訪問版本并報告問題的早期采用者、以及在 OpenJDK 郵件列表中提供反饋的敬業(yè)專業(yè)人員。
Java 16 的新特性
伴隨著數(shù)千個性能、穩(wěn)定性和安全性更新，Java 16 為用戶提供了十七項主要的增強 / 更改（稱為 JDK 增強提案——JEP），包括三個孵化器模塊和一個預覽特性。
孵化器模塊（Incubator Module）中引入了一些增強，這是一種將非最終 API 和非最終工具交給開發(fā)人員的方法，該方法允許用戶提供反饋，從而改善 Java 平臺的質量。
同樣，一些增強被作為 Java SE 平臺的預覽特性、語言或 VM 特性引入，這些增強已完全指定、完全實現(xiàn)但不是永久性的。JDK 特性版本中提供了這些增強，以推動開發(fā)人員根據(jù)實際使用情況提供反饋，這可能會導致它們在將來的版本中永久保留。這為用戶提供了及時反饋的機會，并讓工具供應商有機會在大量 Java 開發(fā)人員在生產中使用特性之前為其提供支持。
Java 16 隨附的 17 個 JEP 分為六個不同類別：
新語言特性
JEP 394，適用于 instanceof 的模式匹配
模式匹配（Pattern Matching）最早在 Java 14 中作為預覽特性引入，在 Java 15 中還是預覽特性。模式匹配通過對 instacneof 運算符進行模式匹配來增強 Java 編程語言。
模式匹配使程序中的通用邏輯（即從對象中有條件地提取組件）得以更簡潔、更安全地表示。
JEP 395，記錄
記錄（Records）在 Java 14 和 Java 15 中作為預覽特性引入。它提供了一種緊湊的語法來聲明類，這些類是淺層不可變數(shù)據(jù)的透明持有者。這將大大簡化這些類，并提高代碼的可讀性和可維護性。
新工具和庫
JEP 380，Unix-Domain 套接字通道
Unix-domain 套接字一直是大多數(shù) Unix 平臺的一個特性，現(xiàn)在在 Windows 10 和 Windows Server 2019 也提供了支持。此特性為 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)回連接更安全、更有效。
JEP 392，打包工具
此特性最初是作為 Java 14 中的一個孵化器模塊引入的，該工具允許打包自包含的 Java 應用程序。它支持原生打包格式，為最終用戶提供自然的安裝體驗，這些格式包括 Windows 上的 msi 和 exe、macOS 上的 pkg 和 dmg，還有 Linux 上的 deb 和 rpm。它還允許在打包時指定啟動時參數(shù)，并且可以從命令行直接調用，也可以通過 ToolProvider API 以編程方式調用。注意 jpackage 模塊名稱從 jdk.incubator.jpackage 更改為 jdk.jpackage。這將改善最終用戶在安裝應用程序時的體驗，并簡化了“應用商店”模型的部署。
為未來做好準備
JEP 390，對基于值的類發(fā)出警告
此特性將原始包裝器類（java.lang.Integer、java.lang.Double 等）指定為基于值的（類似于 java.util.Optional 和 java.time.LocalDateTime），并在其構造器中添加 forRemoval（自 JDK 9 開始被棄用），這樣會提示新的警告。在 Java 平臺中嘗試在任何基于值的類的實例上進行不正確的同步時，它會發(fā)出警告。
許多流行的開源項目已經(jīng)在其源中刪除了包裝構造器調用來響應 Java 9 的棄用警告，并且鑒于“棄用移除”警告的緊迫性，我們可以期望更多開源項目跟上這一步伐。
JEP 396，默認強封裝 JDK 內部元素
此特性會默認強封裝 JDK 的所有內部元素，但關鍵內部 API（例如 sun.misc.Unsafe）除外。默認情況下，使用早期版本成功編譯的訪問 JDK 內部 API 的代碼可能不再起作用。鼓勵開發(fā)人員從使用內部元素遷移到使用標準 API 的方法上，以便他們及其用戶都可以無縫升級到將來的 Java 版本。強封裝由 JDK 9 的啟動器選項–illegal-access 控制，到 JDK 15 默認改為 warning，從 JDK 16 開始默認為 deny。（目前）仍然可以使用單個命令行選項放寬對所有軟件包的封裝，將來只有使用–add-opens 打開特定的軟件包才行。
孵化器和預覽特性
JEP 338，向量 API（孵化器）
該孵化器 API 提供了一個 API 的初始迭代以表達一些向量計算，這些計算在運行時可靠地編譯為支持的 CPU 架構上的最佳向量硬件指令，從而獲得優(yōu)于同等標量計算的性能，充分利用單指令多數(shù)據(jù)（SIMD）技術（大多數(shù)現(xiàn)代 CPU 上都可以使用的一種指令）。盡管 HotSpot 支持自動向量化，但是可轉換的標量操作集有限且易受代碼更改的影響。該 API 將使開發(fā)人員能夠輕松地用 Java 編寫可移植的高性能向量算法。
JEP 389，外部鏈接器 API（孵化器）
該孵化器 API 提供了靜態(tài)類型、純 Java 訪問原生代碼的特性，該 API 將大大簡化綁定原生庫的原本復雜且容易出錯的過程。Java 1.1 就已通過 Java 原生接口（JNI）支持了原生方法調用，但并不好用。Java 開發(fā)人員應該能夠為特定任務綁定特定的原生庫。它還提供了外來函數(shù)支持，而無需任何中間的 JNI 粘合代碼。
JEP 393，外部存儲器訪問 API（第 3 個孵化器）
在 Java 14 和 Java 15 中作為孵化器 API 引入的這個 API 使 Java 程序能夠安全有效地對各種外部存儲器（例如本機存儲器、持久性存儲器、托管堆存儲器等）進行操作。它提供了外部鏈接器 API 的基礎。
JEP 397，密封類（第二預覽）
這個預覽特性可以限制哪些類或接口可以擴展或實現(xiàn)它們；它允許類或接口的作者控制負責實現(xiàn)它的代碼；它還提供了比訪問修飾符更具聲明性的方式來限制對超類的使用。它還通過對模式進行詳盡的分析來支持模式匹配的未來發(fā)展。
提升 OpenJDK 開發(fā)人員的生產力
其余更改對 Java 開發(fā)人員（使用 Java 編寫代碼和運行應用程序的人員）不會直接可見，而只對 Java 開發(fā)人員（參與 OpenJDK 開發(fā)的人員）可見。
JEP 347，啟用 C++14 語言特性（在 JDK 源代碼中）
它允許在 JDK C++ 源代碼中使用 C++14 語言特性，并提供在 HotSpot 代碼中可以使用哪些特性的具體指導。在 JDK 15 中，JDK 中 C++ 代碼使用的語言特性僅限于 C++98/03 語言標準。它要求更新各種平臺編譯器的最低可接受版本
JEP 357，從 Mercurial 遷移到 Git；JEP 369，遷移到 GitHub
這些 JEP 將 OpenJDK 社區(qū)的源代碼存儲庫從 Mercurial（hg）遷移到 Git，并將它們托管在 GitHub 上以供 JDK 11 及更高版本使用，其中包括將 jcheck、webrev 和 defpath 工具等工具更新到 Git。Git 減小了元數(shù)據(jù)的大?。s 1/4），可節(jié)省本地磁盤空間并減少克隆時間。與 Mercurial 相比，現(xiàn)代工具鏈可以更好地與 Git 集成。
Open JDK Git 存儲庫現(xiàn)在位于 https://github.com/openjdk。
JEP 386，AlpineLinux 移植；JEP 388，Windows/AArch64 移植
這些 JEP 的重點不是移植工作本身，而是將它們集成到 JDK 主線存儲庫中；JEP 386 將 JDK 移植到 Alpine Linux 和其他使用 musl 作為 x64 上主要 C 庫的發(fā)行版上。此外，JEP 388 將 JDK 移植到 Windows AArch64（ARM64）。
工具鏈支持
當前的工具鏈支持有助于提高開發(fā)人員的生產力。在 Java 16 中，我們繼續(xù)歡迎領先的 IDE 供應商所做的努力，這些供應商的工具鏈解決方案為開發(fā)人員提供了對當前 Java 版本的支持。開發(fā)人員可以期望通過以下 IDE 獲得對 Java 16 的支持：
JetBrainsIDEA
EclipseIDE
Java 仍然是軟件程序員選擇的 Top 1 編程語言。正如 Java 16 按時交付的各項改進所展示的那樣，通過持續(xù)的深思熟慮的計劃和生態(tài)系統(tǒng)的參與，Java 平臺在現(xiàn)代軟件開發(fā)和云端進化的背景下處于有利地位。
掃碼加入技術交流群，不定時「送書」
推薦閱讀：
絕了！Dataway讓SpringBoot不在需要Controller、Service、DAO、Mapper了
Spring Boot實戰(zhàn)：整合Redis、MyBatis，封裝RedisUtils工具類
最近面試BAT，整理一份面試資料《Java面試BATJ通關手冊》，覆蓋了Java核心技術、JVM、Java并發(fā)、SSM、微服務、數(shù)據(jù)庫、數(shù)據(jù)結構等等。
朕已閱 