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

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

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

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

下載地址：

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

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

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;}

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

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);}

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

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

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

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

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

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

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

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

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

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

其他的一些特性，例如，G1 相關的兩個特性是對 G1 在特定場景不足的有效改進，但談不上是突破性的提高，不再一一列舉。

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

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

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

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

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

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

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

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