在過(guò)去的 2017 年中，Java 世界中發(fā)生了許多前所未有的變化，其部分原因在于 Java 9 的推出，盡管它推后了近一年的時(shí)間。

然而，隨著時(shí)間的推移人們可能會(huì)發(fā)現(xiàn)，推出 Java 9 版本的意義，遠(yuǎn)沒(méi)有隨該新版本一并推出的 Java 版本發(fā)布周期變更為每六個(gè)月一次的意義更為重大。Java 版本發(fā)布周期的變更，意味著在 2018 年將會(huì)推出兩個(gè) Java 新版本，而非一個(gè)。

2018 年將推出的第一個(gè)新版本稱(chēng)為 Java 10，第二個(gè)新版本是 Java 11。雖然這一命名方案與現(xiàn)有命名看上去毫無(wú)二致，但是新版本只有經(jīng)過(guò)重大公開(kāi)辯論并達(dá)成最終共識(shí)后，才能得以推出。

鑒于新版本的推出將切換到這樣一種嚴(yán)格按時(shí)間點(diǎn)的節(jié)奏，預(yù)計(jì)這將使每個(gè)新版本中發(fā)布的 Java 特性，比迄今為止所能看到的范圍更為縮減。就 Java 10 而言，這意味著新特征的數(shù)量將相當(dāng)之少。

InfoQ 先前曾報(bào)道了 Java 10 中的主要特性，一會(huì)也會(huì)再說(shuō)。此后，該版本中添加特性的僅是一些細(xì)微的（Additional Unicode Extensions）、清理性質(zhì)的（移除了原生的頭部生成工具，提供默認(rèn)的 CA 根證書(shū)）、實(shí)驗(yàn)性質(zhì)的（基于 Java 的 JIT 編譯器 Graal），或是當(dāng)前為利基性質(zhì)的 (對(duì)異構(gòu)內(nèi)存架構(gòu)的支持)。

至于 Java 11 中考慮了哪些功能，目前更是云山霧罩。我們只能確認(rèn)下列幾個(gè)功能在考慮范圍內(nèi)：

·Epsilon。一種對(duì) Null 垃圾回收算法的參考實(shí)現(xiàn)。

·Dynamic Class File Constants 。一種主要針對(duì)軟件庫(kù)編寫(xiě)人員及使用動(dòng)態(tài)特性 invokedynamic 高級(jí)開(kāi)發(fā)人員的平臺(tái)特性。

·運(yùn)行時(shí)追蹤 JIT 編譯事件。

一旦發(fā)布日期臨近，該特性列表肯定會(huì)被填滿(mǎn)。但是值得注意的是，列表中目前尚未提及 Java 值類(lèi)型。這也許并不出乎意料，因?yàn)閷?shí)現(xiàn)值類(lèi)型需要對(duì) Java 語(yǔ)言和運(yùn)行時(shí)做重大更改，并對(duì) Java 類(lèi)型系統(tǒng)（包括泛型）做完全重構(gòu)。

盡管當(dāng)前原型已工作，但是距特性交付尚有很長(zhǎng)的路要走。當(dāng)前狀態(tài)只適用于低級(jí)別的平臺(tái)開(kāi)發(fā)人員，以及那些習(xí)慣于使用基于反射（reflective）或 MethodHandle 工具的開(kāi)發(fā)人員?？瓷先チ钊瞬豢伤甲h的是，盡管值類(lèi)型將作為 Java 11 的一部分發(fā)布，但是 Oracle 依然尚未對(duì)該特性預(yù)期于何時(shí)發(fā)布公開(kāi)發(fā)表任何評(píng)論。

但是，如果值類(lèi)型并未作為 Java 11 的一部分提供，這將會(huì)產(chǎn)生連鎖反應(yīng)。包含值類(lèi)型的首個(gè)長(zhǎng)期支持（LTS）版本將不會(huì)在 2021 年 9 月前發(fā)布。

在撰寫(xiě)本文時(shí)，我們尚不清楚已在提案中的數(shù)據(jù)類(lèi)（data classes）特性是否會(huì)出現(xiàn)在 Java 11 中。正如 Java 語(yǔ)言架構(gòu)師 Brian Goetz 所介紹的：

數(shù)據(jù)類(lèi)將用于解決類(lèi)的表示與 API 合約間存在的復(fù)雜間接關(guān)系。通過(guò)使用數(shù)據(jù)類(lèi)，編譯器可以填入一些常規(guī)類(lèi)成員。

展開(kāi)全文

數(shù)據(jù)類(lèi)提案與 Scala 的 Case 類(lèi)具有一些相似之處。但是 Goetz 明確指出，數(shù)據(jù)類(lèi)的設(shè)計(jì)空間中還存在一些可能的變動(dòng)，該特性的整體語(yǔ)義含義要比目前我們能看到的更為深入。目前的數(shù)據(jù)類(lèi)概念是與同處于開(kāi)發(fā)過(guò)程中的模式匹配特性深度關(guān)聯(lián)在一起的。但是，這兩個(gè)特性可能會(huì)在不同的版本中提供。

與上面兩個(gè)特性都相關(guān)的是，未來(lái)可能對(duì) Switch 形式做改進(jìn)。Switch 語(yǔ)句塊將可作為表達(dá)式或聲明使用。

該特性相對(duì)較小，有望在 Java 11 中交付，即便數(shù)據(jù)類(lèi)或模式匹配特性尚未實(shí)現(xiàn)。但目前情況看，該特性仍然是一個(gè) JEP 草案。

最終將于 9 月發(fā)布的版本，其特性完成日期是 2018 年 6 月。因此，在 Java 11 的整體形態(tài)浮出水面之前，我們必須再等待數(shù)月時(shí)間。

說(shuō)回到 Java 10，它的新特性還在確認(rèn)當(dāng)中，所以從現(xiàn)在到 GA 版中間還是有可能加入重大的變更。不管怎樣，在這四個(gè)月里，開(kāi)發(fā)者還是可以期待一些新的特性能夠被添加到 Java 10 中。

新的特性和增強(qiáng)一般通過(guò) Java Enhancement Process（JEP）或 Java Community Process 標(biāo)準(zhǔn)請(qǐng)求（JSR）進(jìn)行跟蹤。因?yàn)?Java 10 的時(shí)間線(xiàn)較短，范圍也相對(duì)較小，所以 Java 10 的變更將通過(guò) JEP 進(jìn)行跟蹤。

有望被包含在 Java 10 中的特性是那些已經(jīng)處于 Targeted 或 Proposed 狀態(tài)的 JEP，它們包括：

·286：本地變量類(lèi)型推斷

·296：統(tǒng)一 JDK 倉(cāng)庫(kù)

·304：垃圾回收器接口

·307：G1 的并行 Full GC

·310：應(yīng)用程序類(lèi)數(shù)據(jù)共享

·312：ThreadLocal 握手機(jī)制

JEP 296 是一次純粹的清理工作，而 JEP 304 加強(qiáng)了不同垃圾回收器的代碼隔離，并為垃圾回收器引入更簡(jiǎn)潔的接口。

JEP 304 意味著廠(chǎng)商可以更自由地選擇特定的 GC 算法來(lái)構(gòu)建 JDK，因?yàn)楝F(xiàn)在有多種處于開(kāi)發(fā)當(dāng)中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未來(lái)可以使用這些 GC 算法。社區(qū)也在努力棄用甚至移除 Concurrent Mark Sweep（CMS）垃圾回收器，只是目前還沒(méi)有可用的替代品。

比較有意思的變更或許是 JEP 286，增強(qiáng)的本地變量類(lèi)型推斷可以讓開(kāi)發(fā)者免去很多變量申明模板代碼。也就是說(shuō)，在下一個(gè)版本中，下面的變量聲明是合法的：

var list = new ArrayListString(); // infers ArrayListString

var stream = list.stream(); // infers StreamString

這種語(yǔ)法只限于初始化過(guò)的本地變量和 for 循環(huán)中的本地變量。

它其實(shí)是個(gè)語(yǔ)法糖，在語(yǔ)義上并沒(méi)有任何變化。不過(guò)，該特性有可能在 Java 開(kāi)發(fā)者當(dāng)中引起熱議。其他三個(gè)變更都將在性能方面帶來(lái)一些影響。

JEP 307 解決了 G1 垃圾回收器的一個(gè)問(wèn)題——截止到 Java 9，G1 的 Full GC 采用的是單線(xiàn)程算法。也就是說(shuō)，G1 在發(fā)生 Full GC 時(shí)會(huì)嚴(yán)重影響性能。JEP 307 的目的就是要采用并行 GC 算法，在發(fā)生 Full GC 時(shí)可以使用多個(gè)線(xiàn)程進(jìn)行并行回收。

JEP 310 對(duì)類(lèi)數(shù)據(jù)共享（CDS）進(jìn)行了擴(kuò)展，JVM 可以將一些類(lèi)記錄到一個(gè)共享的壓縮文件里，在 JVM 下一次啟動(dòng)時(shí)可以將這個(gè)文件映射到 JVM 進(jìn)程，以此來(lái)減少啟動(dòng)時(shí)間。該文件也可以在多個(gè) JVM 間共享，在同一個(gè)機(jī)器上運(yùn)行多個(gè) JVM 時(shí)，這樣做可以減少內(nèi)存占用。

該功能在 Java 5 中就已存在，但截止到 Java 9，該功能只允許 bootstrap 類(lèi)加載器加載壓縮的類(lèi)。JEP 310 的目的是擴(kuò)展該功能，讓?xiě)?yīng)用程序和自定義類(lèi)加載器也能加載壓縮的類(lèi)。該特性目前僅在 Oracle JDK 中可用，OpenJDK 并不包含該特性。

JEP 計(jì)劃將該特性從 Oracle 私有倉(cāng)庫(kù)中遷移到公共倉(cāng)庫(kù)，從 Java 10 往后，常規(guī)版本（非 LTS）將會(huì)使用 OpenJDK 的二進(jìn)制包。此舉表明有用戶(hù)正在使用該特性，所以需要在 OpenJDK 中也支持該特性。

JEP 312 旨在改進(jìn)虛擬機(jī)性能，在應(yīng)用程序線(xiàn)程上調(diào)用回調(diào)不再需要執(zhí)行全局虛擬機(jī)安全點(diǎn)操作，這意味著 JVM 可以停止單個(gè)線(xiàn)程。一些底層小改進(jìn)包括：

·降低堆棧跟蹤取樣所帶來(lái)的影響（如進(jìn)行 profiling）。

·減少信號(hào)依賴(lài)以獲得更好的堆棧取樣。

·通過(guò)停止單獨(dú)線(xiàn)程改進(jìn)偏向鎖。

·從 JVM 移除了一些內(nèi)存屏障。

從整體來(lái)看，Java 10 似乎并沒(méi)有包含重大新特性或性能改進(jìn)。這是可以理解的，畢竟這是新發(fā)布周期下的第一個(gè)版本。