JAVA16版本.JDK16即将发布，你准备好了吗?
歲月無聲，歲月有聲.2020實鼠不易，2021牛轉(zhuǎn)乾坤。 當(dāng)我們開發(fā)者與大多企業(yè)還停留在JDK8的時候，JDK16即將問世，你準備好了嗎？
鄭重申明：
第一次冒險翻譯專業(yè)領(lǐng)域的文獻，可想而知，效果特別糟糕。一般翻譯文獻特別是 技術(shù)專業(yè)領(lǐng)域 的內(nèi)容，因為涉及到很多專業(yè)術(shù)語、業(yè)內(nèi)常用語，很多詞匯你在翻譯軟件根本找不到，并且大部分知識點技術(shù)都是成體系的、相互關(guān)聯(lián)的、多版本迭代的、有歷史原因的等等，因此要求你本身必須清楚每個技術(shù)點的前因后果和邏輯關(guān)系，否則翻譯起來特別耗費時間精力，因為不斷翻閱參考文獻了解學(xué)習(xí)和推敲揣摩，但其實徒勞無功，因為很多你到最后還是沒看明白。而此次翻譯的 JDK 16 新特性 文獻內(nèi)容，確實是難上之難。
前言
到2021年3月，下一版本的 Java 升級發(fā)布將聚焦在原始類、密封類、記錄類、矢量類接口，以及用于 Windows ARM64 和 Alpine Linux 的端口上。
JDK 16 新增了基于值的類警告和密封類（第二次預(yù)覽）作為計劃功能，還加入了一系列新的特性，從外部鏈接程序API，到模式匹配，再到用于垃圾回收的并發(fā)線程堆棧處理。
JDK 16 將是繼9月15日發(fā)布的 JDK 15 之后，一個標(biāo)準的 Java 版本參考實現(xiàn)。擬定發(fā)布計劃是在2020年12月10日和2021年1月14日分別兩次進入提案凍結(jié)階段，隨后在2021年2月4日和2月18日發(fā)布兩個預(yù)覽版本。生產(chǎn)版本預(yù)計在2021年3月16日正式發(fā)布。
縱觀 JDK 史 ：
JDK 1.01996-01-23 發(fā)布JDK 1.11997-02-19 發(fā)布JDK 1.21998-12-04 發(fā)布JDK 1.32000-05-08 發(fā)布JDK 1.42002-02-13 發(fā)布正則表達式，異常鏈，NIO，日志類，XML解析器，XLST 轉(zhuǎn)換器JDK 1.5/5.02004-09-30 發(fā)布自動裝箱、泛型、動態(tài)注解、枚舉、可變長參數(shù)、遍歷循環(huán)JDK 1.6/6.02006-04 提供動態(tài)語言支持、提供編譯 API 和衛(wèi)星 HTTP 服務(wù)器 API，改進 JVM 的鎖，同步垃圾回收，類加載JDK 1.7/7.02011-07-28 發(fā)布提供GI回收器、加強對非Java語言的調(diào)用支持（JSR-292,升級類加載架構(gòu)JDK 1.8/8.02014-03-18 發(fā)布Lambda 表達式、方法引用、默認方法、新工具、Stream API、Date Time API 、Optional 類、Nashorn, JavaScript 引擎JDK 9.02017-09-21 發(fā)布JShell、不可變集合工廠方法、模塊系統(tǒng)、http協(xié)議2.0版本、Process API/CompletableFuture API/Optional Class/Stream API增強、匿名內(nèi)部類的鉆石操作符、默認G1垃圾回收器、try語句語法改進JDK 10.02018-03-21 發(fā)布JIT 編譯器、局部變量類型引用、數(shù)據(jù)類型共享、并行GC、root 證書、javah工具、堆分配JDK 11.02018-09-25 發(fā)布單命令運行Java文件、Lambda 參數(shù)局部變量語法、基于嵌套訪問控制、動態(tài)類文件常量、誤操作垃圾回收器、刪除Java EE和 CORBA 模塊、ChaCha20與Poly1305加密算法、Aarch64增強、ZGC試用、棄用 Nashorn JS引擎JDK 12.02019-03-19 發(fā)布JVM 增強、Switch 表達式、文件 mismatch() 方法、String 新方法 indent()/transform()/describeConstable()/resolveConstantDesc()、JVM常量API、instanceof 模式匹配JDK 13.02019-09-17 發(fā)布支持編寫文本塊、Switch 表達式增強、重構(gòu)遺留的 Socket API、取消提交未使用內(nèi)存、動態(tài)CDS存檔、支持Unicode 12.1、DOM 和 SAX 工廠支持命名空間JDK 14.02020-03-17 發(fā)布空指針異常增強提示、Switch 表達式（標(biāo)準）、instanceof 模式匹配（預(yù)覽）、Records 類（預(yù)覽）、文本塊（第二次預(yù)覽）、打包工具（孵化）、JFR 事件流、ZGC ( 支持 macOS 和 Windows )、外部存儲器訪問API（孵化）JDK 15.02020-09-15 發(fā)布密封類（預(yù)覽）、instanceof 模式匹配（第二次預(yù)覽）、Records 類（第二次預(yù)覽）、文本塊（標(biāo)準）、隱藏類、刪除 Nashorn JS引擎、重構(gòu)遺留的 DatagramSocket API、外部存儲器訪問API（第二次孵化）、棄用RMI激活、移除 Solaris 和 SPARC 的端口JDK 16.02020-12-10 第一次提案凍結(jié)2021-01-14 第二次提案凍結(jié)2021-02-04 發(fā)布第一個預(yù)覽版本2021-02-18 發(fā)布第二個預(yù)覽版本2021-03-16 正式發(fā)布在這里插入圖片描述
截至2020年12月1日，JDK 16 有 15項 正式提案，另外基于值的類警告和密封類（第二次預(yù)覽）2項 仍處于 “針對目標(biāo)提案” 階段。
Java 16 的新特性包括：
1、基于值的類警告提議 將原始包裝類指定為基于值的類，同時不推薦通過提示新棄用警告促使用戶將其構(gòu)造函數(shù)移除。在 Java 平臺中對于任何基于值的類實例進行同步的錯誤嘗試，會予以警告。推動這一努力的是 Valhalla 項目，該項目正在以原始類的形式對 Java 編程模型進行重大改進。原始類將實例聲明為無身份的，并且可以內(nèi)聯(lián)或展平表示形式，其中實例可以在內(nèi)存位置之間自由復(fù)制，并可以使用實例字段的值進行編碼。Java 中原始類的設(shè)計和實現(xiàn)現(xiàn)在已經(jīng)足夠成熟，可以預(yù)見，在將來的發(fā)行版中會把 Java 平臺的某些類遷移至原始類。這些計劃遷移的類在API規(guī)范中將被設(shè)計成 基于值的類。
2、之前在 JDK 15 中進行過預(yù)覽，密封類 和接口限制了可以擴展或?qū)崿F(xiàn)它們的類和接口。這項計劃的目標(biāo)包括：允許類或接口的創(chuàng)建者控制負責(zé)實現(xiàn)它的代碼，提供比訪問修飾符更聲明性的方式來限制超類的使用，并通過提供模式分析基礎(chǔ)來支持模式匹配的未來發(fā)展。
3、默認情況下，JDK 內(nèi)部結(jié)構(gòu)是強封裝的，而關(guān)鍵內(nèi)部API（例如misc.Unsafe）除外。自 JDK 9 以來默認允許用戶選擇使用寬松的強封裝。作為 Jigsaw 項目 的一部分，此提案的目標(biāo)包括提高 JDK 的安全性和可維護性，并鼓勵開發(fā)人員從直接使用內(nèi)部元素逐漸遷移為使用標(biāo)準 API，這樣開發(fā)人員和最終用戶都可以輕松地升級到 Java 的未來版本。該建議確實存在主要風(fēng)險，即現(xiàn)有版本的 Java 代碼將無法運行。鼓勵開發(fā)人員使用 jdeps 工具來識別代碼中依賴的 JDK 內(nèi)部元素，并在可用時切換到 標(biāo)準替代版本。開發(fā)人員可以使用現(xiàn)有的發(fā)行版（如JDK 11）來測試現(xiàn)有代碼，通過使用 --illegal-access=warn 來識別通過反射訪問的內(nèi)部元素，使用 --illegal-access=debug 來定位錯誤的代碼，并使用 --illegal-access=deny 來進行測試。
4、支持靜態(tài)類型的純 Java 方式訪問本地代碼的 外部鏈接程序 API。該接口在 JDK 16 中處于孵化階段，與被提案的外部存儲訪問接口一起，外部鏈接程序接口將會大大減少像其他方式綁定本地庫容易出錯的情況。這項計劃目的在于通過用更高級的純 Java 開發(fā)模式來替換 JNI（Java本機接口），以提供與C語言的交互，并隨著時間的推移，它將更加靈活并適配支持其它平臺（例如32位的x86架構(gòu)）和其他非C語言編寫的外部函數(shù)（例如C++編寫的外部函數(shù)）。它的性能將會比JNI更加優(yōu)越。
5、將 ZGC（可擴展的低延遲垃圾收集器）線程堆棧處理 從安全點移至并發(fā)階段。該計劃的目標(biāo)包括從ZGC安全點中刪除線程堆棧處理，使堆棧處理變得懶性、協(xié)同、并發(fā)和增量，從ZGC安全點移除所有其它單一線程的 root 處理，并為其它虛擬機子系統(tǒng)提供了一種延遲處理堆棧的機制。ZGC旨在使 HotSpot 中的GC暫停和可伸縮性問題成為過去。到目前為止，隨著堆大小和元空間大小變化而伸縮的GC操作已經(jīng)從安全點操作中移除，并遷到并發(fā)階段，它們包括標(biāo)記，重定位，引用處理，類卸載和大多 root 處理。GC安全點中唯一仍保留執(zhí)行的是子集root處理和限時標(biāo)記終止操作。這些 root 處理包括Java線程堆棧和其它線程 root，由于它們會隨線程數(shù)量而伸縮所以會存在問題。要消除這些問題，每個線程的處理（包括堆棧掃描）必須移動到并發(fā)階段。通過這項計劃，提升延遲的吞吐成本將會微不足道，并且在典型計算機上ZGC安全點內(nèi)部花銷的時間將會少于1毫秒。
6、彈性元空間功能 可將未使用的 HotSpot 虛擬機類元數(shù)據(jù)（元空間）占用的內(nèi)存更迅速地返回給操作系統(tǒng)，從而減少元空間占用并簡化元空間代碼以降低維護成本。元空間存在大量的堆外內(nèi)存使用問題。該項計劃呼吁采用內(nèi)存分區(qū)分配方案來替換現(xiàn)有的內(nèi)存分配機制，提供一種將內(nèi)存劃分為多個分區(qū)以滿足內(nèi)存請求的算法。這種方法已在許多地方使用（例如 Linux 內(nèi)核等），它將使得在較小塊中分配內(nèi)存以減少類加載器開銷的方式變得可行，碎片化也將減少。此外，從操作系統(tǒng)到內(nèi)存管理區(qū)域，記憶內(nèi)存都將被延遲、按需使用，以減少加載程序占用的空間，這些加載程序從大型區(qū)域開始占用，但又不立即使用它們或可能無法充分利用它們。為了充分利用分區(qū)分配所提供的彈性，將元空間內(nèi)存排列成大小一致的顆粒，這些顆?？梢员舜霜毩⒌剡M行提交和不提交。
7、啟用C++ 14語言功能，以允許在 JDK C++源代碼中使用 C++ 14 功能，并提供關(guān)于這些允許在 HotSpot 虛擬機代碼中使用的功能的具體指南。通過JDK 15，我們知道在 JDK 中 C++代碼使用的語言特性已限于 C++ 98/03語言標(biāo)準。自 JDK 11，源代碼就已升級為支持使用更新版本的C++標(biāo)準進行構(gòu)建。這包括能夠使用支持 C++ 11/14語言功能的最新版本的編譯器進行構(gòu)建。這項提案不推薦對在 HotSpot 之外使用的C++代碼樣式或用法進行更改，但是要利用C++語言的特性，一些構(gòu)建時的更改是必須的，這取決于平臺編譯器。
8、孵化階段的矢量API，是 JDK 中配備的一個孵化模塊jdk.incubator.vector，用于表達矢量計算————編譯為所支持的 CPU 架構(gòu)上的最佳硬件指令。以實現(xiàn)優(yōu)于同等標(biāo)量計算的性能。矢量API提供了一種使用Java編寫復(fù)雜矢量算法的機制，該機制使用 HotSpot 虛擬機中預(yù)先存在的支持連同一套用戶模型進行矢量化，使其更可預(yù)測且更具健壯性。該提案的目標(biāo)包括提供一個清晰簡潔的API來表達一系列向量計算，通過支持多個 CPU 架構(gòu)實現(xiàn)平臺無關(guān)性，以及在 x64 和 AArch64 架構(gòu)上提供可靠的運行時編譯和性能。優(yōu)雅降級也是一個目標(biāo)，在這個目標(biāo)中，如果向量計算在運行時不能完全表示為硬件向量指令序列，那么向量計算將優(yōu)雅地降級，并且仍然可以正常工作，原因可能是某個架構(gòu)不支持某些指令，或者是其它CPU架構(gòu)不受支持。
9、將JDK移植到 Windows/AArch64 平臺。隨著新的服務(wù)器級和消費類 AArch64（ARM64）硬件的發(fā)布，加上需求原因 Windows/AArch64 已經(jīng)成為一個重要的平臺。雖然移植本身已經(jīng)基本完成，但該項提案的重點是將端口集成到主線JDK庫中。
10、在 x64 和 AArch64 架構(gòu)上，將 JDK移植到 Alpine Linux 和其他使用 musl 作為其主要C庫的 Linux 發(fā)行版。Musl是 ISOC 和 Posix 標(biāo)準中描述的標(biāo)準庫功能的Linux實現(xiàn)。 Alpine Linux 由于鏡像較小而被廣泛應(yīng)用于云部署、微服務(wù)和容器環(huán)境中。Linux 版本的 Docker 容器鏡像小于6MB。讓 Java 在這種設(shè)置中開箱即用，并允許Tomcat、Jetty、Spring和其它流行的框架在本機環(huán)境中正常工作。通過使用 jlink 來減少 Java 運行時的大小，用戶可以創(chuàng)建一個更小的鏡像，以運行特定的應(yīng)用程序。
11、[提供記錄類，作為不可變數(shù)據(jù)的透明載體。記錄類可以認為是名義元組。記錄類在 JDK 14 和 JDK 15 中進行了預(yù)覽。此做法是為了回應(yīng)有關(guān)Java過于冗長拘謹?shù)谋г埂Ｔ撚媱澋哪繕?biāo)包括設(shè)計一個表示簡單值集合的面向?qū)ο蟮臉?gòu)造器，幫助開發(fā)人員專注于對不可變數(shù)據(jù)的建模而不是擴展行為，自動實現(xiàn)數(shù)據(jù)驅(qū)動的方法（例如 equals 和 accessors ），并保留長期的 Java 原則，例如名義類型。
12、Unix-Domain 套接字通道 的添加，其中Unix-Domain（AF_UNIX）套接字支持被添加到 nio.channels 包中的套接字通道和服務(wù)器套接字通道API中。該計劃還擴展了繼承的通道機制，以支持Unix-Domain套接字通道和服務(wù)器套接字通道。Unix-Domain套接字用于同一主機上的進程間通信。它們在大多數(shù)方面與TCP/IP套接字類似，除了它們是通過文件系統(tǒng)路徑名而不是IP地址和端口號尋址的。新功能的目標(biāo)主要是支持Unix平臺和Windows通用的Unix-Domain套接字通道的所有功能。Unix-Domain套接字通道在讀取/寫入行為，連接設(shè)置，服務(wù)器對傳入連接的接受以及在選擇器中與其他非阻塞可選通道的復(fù)用方面將與現(xiàn)有的TCP/IP通道相同。Unix-Domain套接字比用于本地，進程間通信的TCP/IP回送連接更安全，更高效。
13、外部存儲器訪問API，允許Java程序安全地訪問Java堆以外的外部存儲器。外部存儲器訪問API，以前在JDK 14和JDK 15中都進行過孵化，未來在 JDK 16 中將再次孵化，并加以改良。改良范圍包括在 MemorySegment 和 MemoryAddresses 接口之間劃分更明確的角色。此項提案的目標(biāo)包括提供一個可以在各種外部存儲（包括本機，持久化介質(zhì)以及托管堆存儲器）上運行的 API。該 API 不會對虛擬機的安全性造成威脅。該項提案的動機是為了讓很多 Java程序訪問外部存儲，像 Ignite、Memcached 以及 MapDB 。遺憾的是 Java API 還沒有令人滿意的訪問外部存儲的解決方案。
14、在 JDK 14和 JDK 15中都已預(yù)覽過 instanceof 操作符的 模式匹配，它將在JDK 16中最終確定。模式匹配使程序中的通用邏輯（即從對象中有條件地提取組件）得以更簡潔、安全的表達。
15、提供一款名為 jpackage 的工具，用于獨立打包 Java 應(yīng)用程序。jpackage 在 JDK 14 中被作為孵化工具引入，并在 JDK 15 中仍處于孵化階段。到了JDK 16，jpackage 將投入生產(chǎn)，支持本地的軟件包格式，從而為用戶提供自然的安裝體驗，并允許在打包時指定啟動時參數(shù)。支持的格式包括 Windows 上的 msi 和 exe ，MacOS 上的 pkg 和 dmg 以及 Linux 上的 deb 和 rpm 。該工具可以直接從命令行或以編程方式調(diào)用。新的打包工具解決了這樣一種情況：許多Java應(yīng)用程序需要以全局可用的方式安裝在本機平臺上，而不是簡單地放置在類路徑或模塊路徑上。因此提供適合本機平臺的可安裝軟件包非常有必要。
16、OpenJDK 源代碼倉庫從 Mercurial 遷移至 Git。推動這一努力會在幾方面體現(xiàn)優(yōu)勢：版本控制系統(tǒng)元數(shù)據(jù)大小方面、可用工具方面以及托管方面。
17、遷移到 GitHub，這個變化是基于 OpenJDK 源代碼庫從 Mercurial 遷移到 Git，JDK 16源代碼倉庫將出現(xiàn)在流行的代碼共享網(wǎng)站上。Mercurial JDK 和 JDK-sandbox 遷移到 Git、GitHub 和 Skara 的過渡工作已于9月5日完成，現(xiàn)已向用戶開放。
在網(wǎng)站 jdk.java.net 中可以下載到適用于 Linux、Windows 和 MacOS 的 JDK 16 早期測試版本。和JDK 15一樣，JDK 16也會是一個短期版本，僅支持六個月。而計劃在2021年9月發(fā)布的 JDK 17 將會是一個長期支持（LTS）版本，并獲得數(shù)年的支持。當(dāng)前的長期支持（LTS）版本是2018年9月發(fā)布的 JDK 11。總結(jié)
相信很多企業(yè)或個人，目前都還在使用 JDK 8 這個長期維護版本，最新一個長期維護版本是 JDK 11 ，估計使用的人群也還不是特別多，因為對于企業(yè)/個人來說，版本升級的成本太大了，往往我們更加需要的是系統(tǒng)能夠穩(wěn)定安全運作，哪怕是需要犧牲一部分性能。從 JDK8 開始，Java 語言就越顯得更加具有攻擊性和包容性，版本升級速度和周期也是極其驚人，如今短短幾年，已是 JDK 16，所以本人特別看好 Java 在未來市場的占比和技術(shù)能力的持續(xù)延伸，加油，Java 們。
References
[1] JDK 16: https://www.infoworld.com/art…
[2] JDK 15: https://www.infoworld.com/art…
[3] 基于值的類警告提議: https://openjdk.java.net/jeps…
[4] Valhalla 項目: https://openjdk.java.net/proj…
[5] 基于值的類: https://docs.oracle.com/en/ja…
[6] 密封類: https://openjdk.java.net/jeps…
[7] JDK 內(nèi)部結(jié)構(gòu)是強封裝的: https://openjdk.java.net/jeps…
[8] Jigsaw 項目: https://openjdk.java.net/proj…
[9] 標(biāo)準替代版本: https://wiki.openjdk.java.net…'sinternalAPIs
[10] 外部鏈接程序 API: https://openjdk.java.net/jeps…
[11] ZGC（可擴展的低延遲垃圾收集器）線程堆棧處理: https://openjdk.java.net/jeps…
[12] 彈性元空間功能: https://openjdk.java.net/jeps…
[13] 啟用C++ 14語言功能: https://openjdk.java.net/jeps…
[14] C++ 14: https://www.infoworld.com/art…
[15] 孵化階段的矢量API: https://openjdk.java.net/jeps…
[16] 將JDK移植到 Windows/AArch64 平臺: https://openjdk.java.net/jeps…
[17] JDK移植到 Alpine Linux : https://openjdk.java.net/jeps…
[18] jlink: https://openjdk.java.net/jeps…
[19] 提供記錄類: https://openjdk.java.net/jeps…
[20] Unix-Domain 套接字通道: https://openjdk.java.net/jeps…
[21] 外部存儲器訪問API: https://openjdk.java.net/jeps…
[22] 模式匹配: https://openjdk.java.net/jeps…
[23] 提供一款名為 jpackage 的工具，用于獨立打包 Java 應(yīng)用程序: https://openjdk.java.net/jeps…
[24] JDK 14: https://www.infoworld.com/art…
[25] OpenJDK 源代碼倉庫從 Mercurial 遷移至 Git: https://openjdk.java.net/jeps…
[26] 遷移到 GitHub: https://openjdk.java.net/jeps…
[27] JDK 16源代碼倉庫將出現(xiàn)在流行的代碼共享網(wǎng)站上: https://www.infoworld.com/art…
[28] jdk.java.net: https://jdk.java.net/16/
[29] JDK 11: https://www.infoworld.com/art…
總結(jié)
以上是生活随笔為你收集整理的JAVA16版本.JDK16即将发布，你准备好了吗?的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： docker file的介绍
- 下一篇： JAVA16版本.JDK16关于TCP和