Java 16 發(fā)布了，新特性，你知道嗎？
2020 年是值得紀(jì)念的一年，這一年中我們慶祝了 Java 的 25 歲生日。經(jīng)過(guò)二十多年的持續(xù)創(chuàng)新，Java 一直在：
1、通過(guò)適應(yīng)不斷變化的技術(shù)格局來(lái)保持靈活性，同時(shí)維持平臺(tái)獨(dú)立性。2、通過(guò)保持向后兼容性來(lái)保證可靠性。3、在不犧牲安全性的前提下加速創(chuàng)新來(lái)保持優(yōu)勢(shì)。Java 憑借自身不斷提高平臺(tái)性能、穩(wěn)定性和安全性的能力，一直是開(kāi)發(fā)人員中最流行的編程語(yǔ)言。IDC 的最新報(bào)告“Java Turns 25”顯示，超過(guò) 900 萬(wàn)名開(kāi)發(fā)人員（全球?qū)Ｂ氶_(kāi)發(fā)人員中的 69%）在使用 Java——比其他任何語(yǔ)言都多。甲骨文還在繼續(xù)探索 Java 的持續(xù)創(chuàng)新之路，并自豪地宣布 Java 16 正式發(fā)布，這也是我們轉(zhuǎn)向六個(gè)月發(fā)布周期后的第七個(gè)特性版本。這種可預(yù)測(cè)水平使開(kāi)發(fā)人員可以更輕松地管理他們對(duì)創(chuàng)新的采用計(jì)劃。
上圖顯示了自 Java 8 以來(lái)每個(gè)版本的特性數(shù)量甲骨文現(xiàn)在為所有開(kāi)發(fā)人員和企業(yè)提供 Java 16，按照 甲骨文重要補(bǔ)丁更新（CPU）時(shí)間表，甲骨文 JDK 16 將至少獲得兩次季度更新，隨后是甲骨文 JDK 17。Java 17 將于 2021 年 9 月正式發(fā)布，但是 jdk.java.net 已經(jīng)提供了它的早期訪問(wèn)版本。甲骨文再次使用開(kāi)源 GNU 通用公共許可證 v2 和 Classpath Exception（GPLv2+CPE）將 Java 16 作為甲骨文 OpenJDK 版本提供，并且針對(duì)使用甲骨文 JDK 版本作為甲骨文產(chǎn)品或服務(wù)一部分的用戶，或希望能夠獲得商業(yè)支持的用戶提供商業(yè)許可。與之前的版本類似，我們將繼續(xù)感謝來(lái)自 OpenJDK 社區(qū)中眾多個(gè)人和組織對(duì) Java 16 所做的貢獻(xiàn)——我們攜手同行，共同構(gòu)建 Java！JDK 的總體變化率多年來(lái)一直保持基本穩(wěn)定，但是在六個(gè)月的發(fā)布周期下，可用于生產(chǎn)的創(chuàng)新交付速度已大大提高。過(guò)去，我們每隔幾年在大型主要版本中發(fā)布成千上萬(wàn)的修復(fù)和大約一百個(gè) JDK 增強(qiáng)提案（JEP）；而現(xiàn)在，我們改為更易于管理、更容易預(yù)測(cè)的六個(gè)月周期，在較小的特性版本中提供增強(qiáng)特性。這些更改的范圍從重大特性到小型改進(jìn)和例行維護(hù)、錯(cuò)誤修復(fù)和文檔改進(jìn)。每個(gè)更改都在 JDK 錯(cuò)誤系統(tǒng) 中用一個(gè)問(wèn)題的一次提交來(lái)表示。在 Java 16 中標(biāo)記為修復(fù)的 1,897 個(gè)問(wèn)題中，有 1,397 個(gè)由甲骨文工作人員完成，還有 500 個(gè)由個(gè)人開(kāi)發(fā)人員和為其他組織工作的開(kāi)發(fā)人員貢獻(xiàn)。我們整理了貢獻(xiàn)者所在組織的數(shù)據(jù)，得到了以下組織分布圖：
上圖顯示每個(gè)組織貢獻(xiàn)的修復(fù)數(shù)量甲骨文要感謝為 ARM、SAP、RedHat 和騰訊等組織工作的開(kāi)發(fā)人員所做的杰出貢獻(xiàn)，同時(shí)也感謝來(lái)自小型組織（如 Ampere Computing、Bellsoft、DataDog、Microdoc 和獨(dú)立開(kāi)發(fā)人員）的貢獻(xiàn)，他們貢獻(xiàn)了 Java 16 中 3％的修復(fù)。我們同樣感謝許多審查提案更改的經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員、嘗試采用早期訪問(wèn)版本并報(bào)告問(wèn)題的早期采用者、以及在 OpenJDK 郵件列表中提供反饋的敬業(yè)專業(yè)人員。伴隨著數(shù)千個(gè)性能、穩(wěn)定性和安全性更新，Java 16 為用戶提供了十七項(xiàng)主要的增強(qiáng) / 更改（稱為 JDK 增強(qiáng)提案——JEP），包括三個(gè)孵化器模塊和一個(gè)預(yù)覽特性。孵化器模塊（Incubator Module）中引入了一些增強(qiáng)，這是一種將非最終 API 和非最終工具交給開(kāi)發(fā)人員的方法，該方法允許用戶提供反饋，從而改善 Java 平臺(tái)的質(zhì)量。同樣，一些增強(qiáng)被作為 Java SE 平臺(tái)的預(yù)覽特性、語(yǔ)言或 VM 特性引入，這些增強(qiáng)已完全指定、完全實(shí)現(xiàn)但不是永久性的。JDK 特性版本中提供了這些增強(qiáng)，以推動(dòng)開(kāi)發(fā)人員根據(jù)實(shí)際使用情況提供反饋，這可能會(huì)導(dǎo)致它們?cè)趯?lái)的版本中永久保留。這為用戶提供了及時(shí)反饋的機(jī)會(huì)，并讓工具供應(yīng)商有機(jī)會(huì)在大量 Java 開(kāi)發(fā)人員在生產(chǎn)中使用特性之前為其提供支持。Java 16 隨附的 17 個(gè) JEP 分為六個(gè)不同類別： JEP 394，適用于 instanceof 的模式匹配模式匹配（Pattern Matching）最早在 Java 14 中作為預(yù)覽特性引入，在 Java 15 中還是預(yù)覽特性。模式匹配通過(guò)對(duì) instacneof 運(yùn)算符進(jìn)行模式匹配來(lái)增強(qiáng) Java 編程語(yǔ)言。模式匹配使程序中的通用邏輯（即從對(duì)象中有條件地提取組件）得以更簡(jiǎn)潔、更安全地表示。記錄（Records）在 Java 14 和 Java 15 中作為預(yù)覽特性引入。它提供了一種緊湊的語(yǔ)法來(lái)聲明類，這些類是淺層不可變數(shù)據(jù)的透明持有者。這將大大簡(jiǎn)化這些類，并提高代碼的可讀性和可維護(hù)性。JEP 376 將 ZGC 線程棧處理從安全點(diǎn)轉(zhuǎn)移到一個(gè)并發(fā)階段，甚至在大堆上也允許在毫秒內(nèi)暫停 GC 安全點(diǎn)。消除 ZGC 垃圾收集器中最后一個(gè)延遲源可以極大地提高應(yīng)用程序的性能和效率。此特性可將未使用的 HotSpot 類元數(shù)據(jù)（即元空間，metaspace）內(nèi)存更快速地返回到操作系統(tǒng)，從而減少元空間的占用空間。具有大量類加載和卸載活動(dòng)的應(yīng)用程序可能會(huì)占用大量未使用的空間。新方案將元空間內(nèi)存按較小的塊分配，它將未使用的元空間內(nèi)存返回給操作系統(tǒng)來(lái)提高彈性，從而提高應(yīng)用程序性能并降低內(nèi)存占用。 JEP 380，Unix-Domain 套接字通道Unix-domain 套接字一直是大多數(shù) Unix 平臺(tái)的一個(gè)特性，現(xiàn)在在 Windows 10 和 Windows Server 2019 也提供了支持。此特性為 java.nio.channels 包的套接字通道和服務(wù)器套接字通道 API 添加了 Unix-domain（AF_UNIX）套接字支持。它擴(kuò)展了繼承的通道機(jī)制以支持 Unix-domain 套接字通道和服務(wù)器套接字通道。Unix-domain 套接字用于同一主機(jī)上的進(jìn)程間通信（IPC）。它們?cè)诤艽蟪潭壬项愃朴?TCP/IP，區(qū)別在于套接字是通過(guò)文件系統(tǒng)路徑名而不是 Internet 協(xié)議（IP）地址和端口號(hào)尋址的。對(duì)于本地進(jìn)程間通信，Unix-domain 套接字比 TCP/IP 環(huán)回連接更安全、更有效。此特性最初是作為 Java 14 中的一個(gè)孵化器模塊引入的，該工具允許打包自包含的 Java 應(yīng)用程序。它支持原生打包格式，為最終用戶提供自然的安裝體驗(yàn)，這些格式包括 Windows 上的 msi 和 exe、macOS 上的 pkg 和 dmg，還有 Linux 上的 deb 和 rpm。它還允許在打包時(shí)指定啟動(dòng)時(shí)參數(shù)，并且可以從命令行直接調(diào)用，也可以通過(guò) ToolProvider API 以編程方式調(diào)用。注意 jpackage 模塊名稱從 jdk.incubator.jpackage 更改為 jdk.jpackage。這將改善最終用戶在安裝應(yīng)用程序時(shí)的體驗(yàn)，并簡(jiǎn)化了“應(yīng)用商店”模型的部署。 JEP 390，對(duì)基于值的類發(fā)出警告此特性將原始包裝器類（java.lang.Integer、java.lang.Double 等）指定為基于值的（類似于 java.util.Optional 和 java.time.LocalDateTime），并在其構(gòu)造器中添加 forRemoval（自 JDK 9 開(kāi)始被棄用），這樣會(huì)提示新的警告。在 Java 平臺(tái)中嘗試在任何基于值的類的實(shí)例上進(jìn)行不正確的同步時(shí)，它會(huì)發(fā)出警告。許多流行的開(kāi)源項(xiàng)目已經(jīng)在其源中刪除了包裝構(gòu)造器調(diào)用來(lái)響應(yīng) Java 9 的棄用警告，并且鑒于“棄用移除”警告的緊迫性，我們可以期望更多開(kāi)源項(xiàng)目跟上這一步伐。 JEP 396，默認(rèn)強(qiáng)封裝 JDK 內(nèi)部元素此特性會(huì)默認(rèn)強(qiáng)封裝 JDK 的所有內(nèi)部元素，但關(guān)鍵內(nèi)部 API（例如 sun.misc.Unsafe）除外。默認(rèn)情況下，使用早期版本成功編譯的訪問(wèn) JDK 內(nèi)部 API 的代碼可能不再起作用。鼓勵(lì)開(kāi)發(fā)人員從使用內(nèi)部元素遷移到使用標(biāo)準(zhǔn) API 的方法上，以便他們及其用戶都可以無(wú)縫升級(jí)到將來(lái)的 Java 版本。強(qiáng)封裝由 JDK 9 的啟動(dòng)器選項(xiàng)–illegal-access 控制，到 JDK 15 默認(rèn)改為 warning，從 JDK 16 開(kāi)始默認(rèn)為 deny。（目前）仍然可以使用單個(gè)命令行選項(xiàng)放寬對(duì)所有軟件包的封裝，將來(lái)只有使用–add-opens 打開(kāi)特定的軟件包才行。該孵化器 API 提供了一個(gè) API 的初始迭代以表達(dá)一些向量計(jì)算，這些計(jì)算在運(yùn)行時(shí)可靠地編譯為支持的 CPU 架構(gòu)上的最佳向量硬件指令，從而獲得優(yōu)于同等標(biāo)量計(jì)算的性能，充分利用單指令多數(shù)據(jù)（SIMD）技術(shù)（大多數(shù)現(xiàn)代 CPU 上都可以使用的一種指令）。盡管 HotSpot 支持自動(dòng)向量化，但是可轉(zhuǎn)換的標(biāo)量操作集有限且易受代碼更改的影響。該 API 將使開(kāi)發(fā)人員能夠輕松地用 Java 編寫(xiě)可移植的高性能向量算法。該孵化器 API 提供了靜態(tài)類型、純 Java 訪問(wèn)原生代碼的特性，該 API 將大大簡(jiǎn)化綁定原生庫(kù)的原本復(fù)雜且容易出錯(cuò)的過(guò)程。Java 1.1 就已通過(guò) Java 原生接口（JNI）支持了原生方法調(diào)用，但并不好用。Java 開(kāi)發(fā)人員應(yīng)該能夠?yàn)樘囟ㄈ蝿?wù)綁定特定的原生庫(kù)。它還提供了外來(lái)函數(shù)支持，而無(wú)需任何中間的 JNI 粘合代碼。 JEP 393，外部存儲(chǔ)器訪問(wèn) API（第 3 個(gè)孵化器）在 Java 14 和 Java 15 中作為孵化器 API 引入的這個(gè) API 使 Java 程序能夠安全有效地對(duì)各種外部存儲(chǔ)器（例如本機(jī)存儲(chǔ)器、持久性存儲(chǔ)器、托管堆存儲(chǔ)器等）進(jìn)行操作。它提供了外部鏈接器 API 的基礎(chǔ)。這個(gè)預(yù)覽特性可以限制哪些類或接口可以擴(kuò)展或?qū)崿F(xiàn)它們；它允許類或接口的作者控制負(fù)責(zé)實(shí)現(xiàn)它的代碼；它還提供了比訪問(wèn)修飾符更具聲明性的方式來(lái)限制對(duì)超類的使用。它還通過(guò)對(duì)模式進(jìn)行詳盡的分析來(lái)支持模式匹配的未來(lái)發(fā)展。提升 OpenJDK 開(kāi)發(fā)人員的生產(chǎn)力其余更改對(duì) Java 開(kāi)發(fā)人員（使用 Java 編寫(xiě)代碼和運(yùn)行應(yīng)用程序的人員）不會(huì)直接可見(jiàn)，而只對(duì) Java 開(kāi)發(fā)人員（參與 OpenJDK 開(kāi)發(fā)的人員）可見(jiàn)。 JEP 347，啟用 C++14 語(yǔ)言特性（在 JDK 源代碼中）它允許在 JDK C++ 源代碼中使用 C++14 語(yǔ)言特性，并提供在 HotSpot 代碼中可以使用哪些特性的具體指導(dǎo)。在 JDK 15 中，JDK 中 C++ 代碼使用的語(yǔ)言特性僅限于 C++98/03 語(yǔ)言標(biāo)準(zhǔn)。它要求更新各種平臺(tái)編譯器的最低可接受版本 JEP 357，從 Mercurial 遷移到 Git；JEP 369，遷移到 GitHub這些 JEP 將 OpenJDK 社區(qū)的源代碼存儲(chǔ)庫(kù)從 Mercurial（hg）遷移到 Git，并將它們托管在 GitHub 上以供 JDK 11 及更高版本使用，其中包括將 jcheck、webrev 和 defpath 工具等工具更新到 Git。Git 減小了元數(shù)據(jù)的大小（約 1/4），可節(jié)省本地磁盤(pán)空間并減少克隆時(shí)間。與 Mercurial 相比，現(xiàn)代工具鏈可以更好地與 Git 集成。Open JDK Git 存儲(chǔ)庫(kù)現(xiàn)在位于 https://github.com/openjdk。 JEP 386，AlpineLinux 移植；JEP 388，Windows/AArch64 移植這些 JEP 的重點(diǎn)不是移植工作本身，而是將它們集成到 JDK 主線存儲(chǔ)庫(kù)中；JEP 386 將 JDK 移植到 Alpine Linux 和其他使用 musl 作為 x64 上主要 C 庫(kù)的發(fā)行版上。此外，JEP 388 將 JDK 移植到 Windows AArch64（ARM64）。當(dāng)前的工具鏈支持有助于提高開(kāi)發(fā)人員的生產(chǎn)力。在 Java 16 中，我們繼續(xù)歡迎領(lǐng)先的 IDE 供應(yīng)商所做的努力，這些供應(yīng)商的工具鏈解決方案為開(kāi)發(fā)人員提供了對(duì)當(dāng)前 Java 版本的支持。開(kāi)發(fā)人員可以期望通過(guò)以下 IDE 獲得對(duì) Java 16 的支持：Java 仍然是軟件程序員選擇的 Top 1 編程語(yǔ)言。正如 Java 16 按時(shí)交付的各項(xiàng)改進(jìn)所展示的那樣，通過(guò)持續(xù)的深思熟慮的計(jì)劃和生態(tài)系統(tǒng)的參與，Java 平臺(tái)在現(xiàn)代軟件開(kāi)發(fā)和云端進(jìn)化的背景下處于有利地位。來(lái)源：http://t.hk.uy/efG往期推薦
想要搭建個(gè)人博客？這4個(gè)Java 開(kāi)源博客系統(tǒng)，真香
畢業(yè)設(shè)計(jì)：Java簡(jiǎn)易學(xué)生宿舍管理系統(tǒng)
SpringBoot+Vue 完整的外賣系統(tǒng)，手機(jī)端和后臺(tái)管理，附源碼！
帶工作流的SpringBoot后臺(tái)管理項(xiàng)目，一個(gè)企業(yè)級(jí)快速開(kāi)發(fā)解決方案
哈哈哈，徒手給小區(qū)開(kāi)發(fā)一套系統(tǒng)！看能換一個(gè)停車位不....
最近面試BAT，整理一份面試資料《Java面試BAT通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。獲取方式：關(guān)注公眾號(hào)并回復(fù) java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
