可以在jdk.java.net上找到適用于Linux，Windows和MacOS的JDK 16的早期版本。與JDK 15一樣，JDK 16將是一個短期版本，支持六個月。將于2021年9月發(fā)布的JDK 17將是一個長期支持(LTS)版本，將獲得數(shù)年的支持。當前的LTS版本JDK 11已于2018年9月發(fā)布。

JDK 16將作為標準Java版本的參考實現(xiàn)，將在明年3月到來。

截至10月8日，八項提案正式針對JDK16。Java16的新功能包括：

• 將ZGC(Z垃圾收集器)線程堆棧處理從安全點safepoints遷移到并發(fā)階段。該計劃的目標包括從ZGC安全點中刪除線程堆棧處理。使堆棧處理變得惰性，協(xié)作，并發(fā)和增量;從ZGC安全點刪除所有其他每線程根處理;并為其他HotSpot VM子系統(tǒng)提供了一種機制來延遲處理堆棧。這樣，ZGC使HotSpot中的GC暫停和可伸縮性問題成為過去。到目前為止，隨著堆大小和元空間大小而擴展的GC操作已經從安全點操作中移出并進入并發(fā)階段。這些包括標記，重定位，參考處理，類卸載和大多數(shù)根處理。GC安全點中唯一仍進行的活動是根處理和有時間限制的標記終止操作的子集。這些根目錄包括Java線程堆棧和其他線程根目錄，這些根目錄存在問題，因為它們隨線程數(shù)的增長而擴展。為了超越當前狀況，必須將包括堆棧掃描在內的每線程處理移至并發(fā)階段。使用此計劃，改進的延遲的吞吐成本應該是微不足道的，并且在典型計算機上的ZGC安全點內花費的時間應少于一毫秒。
• 彈性元空間能力，它可以將未使用的HotSpot VM類元數(shù)據(jù)(元空間)內存更迅速地返回給操作系統(tǒng)，從而減少了元空間的占用空間并簡化了元空間代碼，從而降低了維護成本。元空間存在大量的堆外內存使用問題。該計劃要求用基于伙伴的分配方案替換現(xiàn)有的內存分配器，提供一種將內存劃分為多個分區(qū)以滿足內存請求的算法。這種方法已在Linux內核等地方使用，它將使在較小的塊中分配內存以減少類加載器的開銷變得切實可行。碎片也將減少。此外，從操作系統(tǒng)到內存管理領域的內存承諾將根據(jù)需要延遲執(zhí)行，減少了從大型舞臺開始但不立即使用它們或可能未完全使用它們的裝載機的占地面積。為了充分利用伙伴分配所提供的彈性，將元空間內存排列成大小統(tǒng)一的顆粒，這些顆粒可以彼此獨立地進行提交和不提交。
• 啟用C ++ 14語言功能，以允許在JDK C ++源代碼中使用C ++ 14功能，并提供有關在HotSpot VM代碼中可以使用其中哪些功能的特定指南。通過JDK 15，JDK中C ++代碼使用的語言功能已限于C ++ 98/03語言標準。使用JDK 11，源代碼已更新，以支持使用更新版本的C ++標準進行構建。這包括能夠使用支持C ++ 11/14語言功能的最新版本的編譯器進行構建。本提案不建議在HotSpot之外使用的C ++代碼的樣式或用法更改。但是要利用C ++語言功能，需要進行一些構建時更改，具體取決于平臺編譯器。
• 孵化器階段的矢量API，其中JDK將裝有一個孵化器模塊，jdk.incubator.vector，以表達可在支持的CPU架構上編譯為最佳矢量硬件指令的矢量計算，以實現(xiàn)優(yōu)于等效標量計算的性能。向量API提供了一種使用Java編寫復雜向量算法的機制，該機制使用HotSpot VM中預先存在的支持進行向量化，但其用戶模型使向量化更可預測且更可靠。該提案的目標包括提供一個清晰簡潔的API來表達一系列矢量計算，通過支持多種CPU架構而與平臺無關，在x64和AArch64架構上提供可靠的運行時編譯和性能。優(yōu)雅降級也是一個目標，
• 將JDK移植到Windows / AArch64平臺。隨著新的服務器類和消費類AArch64(ARM64)硬件的發(fā)布，由于需求，Windows / AArch64已成為重要的平臺。盡管移植本身已經基本完成，但該建議的重點是將端口集成到主線JDK存儲庫中。
• 在x64和AArch64體系結構上，將JDK移植到Alpine Linux和其他使用musl作為其主要C庫的Linux發(fā)行版。Musl是ISO C和Posix標準中描述的標準庫功能的Linux實現(xiàn)。由于Alpine Linux的映像較小，因此已在云部署，微服務和容器環(huán)境中廣泛采用。Linux的Docker映像小于6MB。在這樣的設置中讓Java開箱即用地運行，將允許Tomcat，Jetty，Spring和其他流行的框架在這​​些環(huán)境中本機運行。通過使用jlink減小Java運行時的大小，用戶可以創(chuàng)建專門為運行特定應用程序而定制的甚至更小的映像。
• OpenJDK源代碼庫從Mercurial遷移到Git。推動這一努力的是版本控制系統(tǒng)元數(shù)據(jù)大小以及可用工具和托管方面的優(yōu)勢。
• 遷移到GitHub，與從Mercurial到Git的遷移有關，JDK 16源代碼存儲庫位于流行的代碼共享站點上。Mercurial JDK和JDK-sandbox的向Git，GitHub和Skara的過渡已于9月5日完成，現(xiàn)已開放供稿。