Java 12正式發佈,新特性解讀!

Java 12 如約而至,除了那些值得關注的特性,你也應該思考下 Java 的未來。

 

寫在前面:

在 Java 9 之前,當一個版本被宣佈爲首選版本,存在一個“培育”(bedded-in)新 GA 版本的重疊期。在此期間,上一個版本將會繼續進行免費更新。爲確保新舊版本間的乾淨切換,即便舊版本已不再是首選版本,通常也會繼續維護 12 個月以上。但是隨着 Java 版本發佈更改爲遵循嚴格的時間表後,事實上宣告了傳統的免費支持期將壽終正寢。

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

Java 是很多程序員的飯碗,Java 生態圈下的程序員們似乎對於 Oracle 也有諸多不滿,當 Java 也像 Android 系統走上版本號的穩定道路後,新版本的發佈意義還有那麼大嗎?Java 12 已經發布了,但使用版本最多的還是 Java 8,你會選擇升級嗎?


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

下載地址:

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,這是一個爲開發者準備的特性,我們可以利用具體代碼快速瞭解一下,下面是傳統 statement 形式的 switch 語法:


 

switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
System.out.println(6);
break;
case TUESDAY:
System.out.println(7);
break;
case THURSDAY:
case SATURDAY:
System.out.println(8);
break;
case WEDNESDAY:
System.out.println(9);
break;
}

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


 

switch (day) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
case TUESDAY -> System.out.println(7);
case THURSDAY, SATURDAY -> System.out.println(8);
case WEDNESDAY -> System.out.println(9);
}

更進一步,下面的表達式,爲我們提供了優雅地表達特定場合計算邏輯的方式


 

int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};

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

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

也許瞭解 Shenandoah GC 的人比較少,業界聲音比較響亮的是 Oracle 在 JDK11 中開源出來的 ZGC,或者商業版本的 Azul C4(Continuously Concurrent Compacting Collector)。但是,筆者認爲,至少目前,其實際意義大於後兩者,因爲:

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

  • 而 C4,畢竟是土豪們的選擇,現實情況是,有多少公司連個幾十塊錢的 License 都不捨得…

  • 而 Shenandoah GC 可是有穩定的 JDK8u 版本發佈的哦,據我所知已經有個別公司在 HBase 等高實時性產品中實踐許久。

從原理的角度,我們可以參考該項目官方的示意圖,其內存結構與 G1 非常相似,都是將內存劃分爲類似棋盤的 region。整體流程與 G1 也是比較相似的,最大的區別在於實現了併發的 Evacuation 環節,引入的 Brooks Forwarding Pointer 技術使得 GC 在移動對象時,對象引用仍然可以訪問。

 

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

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

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

  • JDK12 這種非 LTS 版本,是否有什麼生產環境價值?

  • Java 新的發佈模式是否達到了其快速落地和迭代新特性的目的?

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

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

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

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

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

關於更多java方面的問題,你可以加入我的java學習交流羣:494801931,歡迎java初學者和進階者的加入。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章