在 Java 9 之前，當(dāng)一個(gè)版本被宣布為首選版本，存在一個(gè)“培育”（bedded-in）新 GA 版本的重疊期。在此期間，上一個(gè)版本將會(huì)繼續(xù)進(jìn)行免費(fèi)更新。為確保新舊版本間的干凈切換，即便舊版本已不再是首選版本，通常也會(huì)繼續(xù)維護(hù) 12 個(gè)月以上。但是隨著 Java 版本發(fā)布更改為遵循嚴(yán)格的時(shí)間表后，事實(shí)上宣告了傳統(tǒng)的免費(fèi)支持期將壽終正寢。

Oracle 對(duì) Java 8 的官方支持時(shí)間持續(xù)到 2020 年 12 月，之后將不再為個(gè)人桌面用戶提供 Oracle JDK 8 的修復(fù)更新；在 2019 年 1 月之后，不再提供免費(fèi)的商業(yè)版本更新，屆時(shí)想要繼續(xù)獲得 Oracle 的商業(yè)支持和維護(hù)，需付費(fèi)訂閱。

Java 是很多程序員的飯碗，Java 生態(tài)圈下的程序員們似乎對(duì)于 Oracle 也有諸多不滿，當(dāng) Java 也像 Android 系統(tǒng)走上版本號(hào)的穩(wěn)定道路后，新版本的發(fā)布意義還有那么大嗎？Java 12 已經(jīng)發(fā)布了，但使用版本最多的還是 Java 8，你會(huì)選擇升級(jí)嗎？

JDK12 如期而至，不知不覺 Java 半年為周期的發(fā)布模式（Half-year-cadence）已經(jīng)成功運(yùn)行了一年多，OpenJDK 社區(qū)和 Oracle 充分展示了其堅(jiān)決的執(zhí)行力。今天當(dāng)然要嘗鮮 JDK12 的新特性，與此同時(shí)，筆者也會(huì)從不同角度，來分析新發(fā)布模式是否達(dá)到了其初衷。

下載地址：

https://www.oracle.com/technetwork/java/javase/downloads/index.html

JDK 12 新特性一覽：

189：Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

http://openjdk.java.net/jeps/189

230：Microbenchmark Suite

http://openjdk.java.net/jeps/230

325：Switch Expressions (Preview)

http://openjdk.java.net/jeps/325

334：JVM Constants API

http://openjdk.java.net/jeps/334

340：One AArch64 Port, Not Two

http://openjdk.java.net/jeps/340

341：Default CDS Archives

http://openjdk.java.net/jeps/341

344：Abortable Mixed Collections for G1

http://openjdk.java.net/jeps/344

346：Promptly Return Unused Committed Memory from G1

http://openjdk.java.net/jeps/346

首先值得關(guān)注的是 Switch Expressions，這是一個(gè)為開發(fā)者準(zhǔn)備的特性，我們可以利用具體代碼快速了解一下，下面是傳統(tǒng) statement 形式的 switch 語(yǔ)法：

switch(day) {caseMONDAY:caseFRIDAY:caseSUNDAY:System.out.println(6);break;caseTUESDAY:System.out.println(7);break;caseTHURSDAY:caseSATURDAY:System.out.println(8);break;caseWEDNESDAY:System.out.println(9);break;}

如果有編碼經(jīng)驗(yàn)，你一定知道，switch 語(yǔ)句如果漏寫了一個(gè) break，那么邏輯往往就跑偏了，這種方式既繁瑣，又容易出錯(cuò)。如果換成 switch 表達(dá)式，Pattern Matching 機(jī)制能夠自然地保證只有單一路徑會(huì)被執(zhí)行，請(qǐng)看下面的代碼示例：

switch(day) {caseMONDAY, FRIDAY, SUNDAY -> System.out.println(6);caseTUESDAY -> System.out.println(7);caseTHURSDAY, SATURDAY -> System.out.println(8);caseWEDNESDAY -> System.out.println(9);}

更進(jìn)一步，下面的表達(dá)式，為我們提供了優(yōu)雅地表達(dá)特定場(chǎng)合計(jì)算邏輯的方式

intnumLetters =switch(day) {caseMONDAY, FRIDAY, SUNDAY ->6;caseTUESDAY ->7;caseTHURSDAY, SATURDAY ->8;caseWEDNESDAY ->9;};

Switch Expressions 或者說起相關(guān)的 Pattern Matching 特性，為我們提供了勾勒出了 Java 語(yǔ)法進(jìn)化的一個(gè)趨勢(shì)，將開發(fā)者從復(fù)雜繁瑣的低層次抽象中逐漸解放出來，以更高層次更優(yōu)雅的抽象，既降低代碼量，又避免意外編程錯(cuò)誤的出現(xiàn)，進(jìn)而提高代碼質(zhì)量和開發(fā)效率。

第二，則是很有現(xiàn)實(shí)意義度 Shenandoah GC。它是 Redhat 主導(dǎo)開發(fā)的 Pauseless GC 實(shí)現(xiàn)，從大概 2013 年開始研發(fā)，終于取得了重要的階段性成果，與其他 Pauseless GC 類似，Shenandoah GC 主要目標(biāo)是 99.9% 的暫停小于 10ms，暫停與堆大小無(wú)關(guān)等。

也許了解 Shenandoah GC 的人比較少，業(yè)界聲音比較響亮的是 Oracle 在 JDK11 中開源出來的 ZGC，或者商業(yè)版本的 Azul C4（Continuously Concurrent Compacting Collector）。但是，筆者認(rèn)為，至少目前，其實(shí)際意義大于后兩者，因?yàn)椋?/p>

使用 ZGC 的最低門檻是升級(jí)到 JDK11，對(duì)很多團(tuán)隊(duì)來說，這種版本的跳躍并不是非常低成本的事情，更何況是尚不清楚 ZGC 在自身業(yè)務(wù)場(chǎng)景中的實(shí)際表現(xiàn)如何。

而 C4，畢竟是土豪們的選擇，現(xiàn)實(shí)情況是，有多少公司連個(gè)幾十塊錢的 License 都不舍得…

而 Shenandoah GC 可是有穩(wěn)定的 JDK8u 版本發(fā)布的哦，據(jù)我所知已經(jīng)有個(gè)別公司在 HBase 等高實(shí)時(shí)性產(chǎn)品中實(shí)踐許久。

從原理的角度，我們可以參考該項(xiàng)目官方的示意圖，其內(nèi)存結(jié)構(gòu)與 G1 非常相似，都是將內(nèi)存劃分為類似棋盤的 region。整體流程與 G1 也是比較相似的，最大的區(qū)別在于實(shí)現(xiàn)了并發(fā)的 Evacuation 環(huán)節(jié)，引入的 Brooks Forwarding Pointer 技術(shù)使得 GC 在移動(dòng)對(duì)象時(shí)，對(duì)象引用仍然可以訪問。

下面是 jbb15 benchmark 中，Shenandoah GC 相對(duì)于其他主流 GC 的表現(xiàn)，GC 暫停相比于 CMS 等選擇有數(shù)量級(jí)程度的提高，對(duì)于 GC 暫停非常敏感的場(chǎng)景，價(jià)值還是很明顯的，能夠在 SLA 層面有顯著提高。當(dāng)然，這種對(duì)于低延遲的保證，也是以消耗 CPU 等計(jì)算資源為代價(jià)的，實(shí)際吞吐量表現(xiàn)也不是非常明朗，需要看企業(yè)的實(shí)際場(chǎng)景需求，并不是一個(gè)一勞永逸的解決方案。

其他的一些特性，例如，G1 相關(guān)的兩個(gè)特性是對(duì) G1 在特定場(chǎng)景不足的有效改進(jìn)，但談不上是突破性的提高，不再一一列舉。

與 JDK11 這種長(zhǎng)期支持版本（Long-Term-Support，LTS）相比，JDK12 似乎關(guān)注度有限，大家對(duì)于 JDK 這種頻繁的節(jié)奏也有點(diǎn)麻木了，那么

JDK12 這種非 LTS 版本，是否有什么生產(chǎn)環(huán)境價(jià)值？

Java 新的發(fā)布模式是否達(dá)到了其快速落地和迭代新特性的目的？

也許不會(huì)有太多公司直接選擇 JDK12，但個(gè)別的生產(chǎn)實(shí)踐并不遙遠(yuǎn)。比如，我所在部門在實(shí)踐場(chǎng)景中發(fā)現(xiàn)，利用 JDK 12 的 Abortable Mixed Collections for G1，解決了 HDFS 在特定場(chǎng)景中 G1 Evacuation 時(shí)間過長(zhǎng)的困擾，雖然最后團(tuán)隊(duì)選擇將其 backport 到了自己的 JDK11 版本中，但如果沒有快速交付的預(yù)覽版 JDK12，也不會(huì)如此快速的得到結(jié)論。

而對(duì)另一個(gè)問題，筆者認(rèn)為目前看是非常成功的，解開了 Java/JVM 演進(jìn)的許多枷鎖，至關(guān)重要的是，OpenJDK 的權(quán)力中心，正在轉(zhuǎn)移到開發(fā)社區(qū)和開發(fā)者手中。在新的模式中，既可以利用 LTS 滿足企業(yè)長(zhǎng)期可靠支持的需求，也可以滿足各種開發(fā)者對(duì)于新特性迭代的訴求。你可能注意到了 Switch Expressions 被打上了預(yù)覽（Preview）的標(biāo)簽，Shenandoah GC 則是實(shí)驗(yàn)（Experimental）特性，這些都是以往的發(fā)布周期下不大現(xiàn)實(shí)的，因?yàn)橛?2-3 年的最小間隔粒度來實(shí)驗(yàn)一個(gè)特性，基本是不現(xiàn)實(shí)的。

可以預(yù)計(jì)，JDK8 在未來的一段時(shí)間仍將是主流，我們已經(jīng)注意到 Amazon、Alibaba、Redhat、AdoptOpenJDK 等等廠商或社區(qū)，紛紛發(fā)布了自己的 JDK8 等產(chǎn)品，開始競(jìng)賽長(zhǎng)期支持版本 JDK 的主導(dǎo)權(quán)，筆者認(rèn)為這是非常好的跡象，反映了主流廠商對(duì)于 Java 的投資力度增大。

是否會(huì)帶來 Java/JVM 的碎片化呢？多少會(huì)發(fā)生一些，但從目前的合作模式來看，OpenJDK 仍然是合作的中心，主導(dǎo)這 Java 歷史版本維護(hù)和未來的演進(jìn)路線。

一些小鮮肉語(yǔ)言嘲笑 Java，實(shí)現(xiàn)類似功能，Java 代碼要多寫近一倍，程序要笨重一個(gè)數(shù)量級(jí)，有些也許是言過其實(shí)，但語(yǔ)法的表達(dá)能力和 JVM 的龐大，確實(shí)逐漸成為 Java 發(fā)展的短板，JDK10～12 發(fā)布的不間斷成功，讓我們看到了 Java/JVM 大踏步前進(jìn)的曙光！