Java 12正式发布，新特性解读！

亦凉 2022-02-22 07:34 338阅读 0赞

> 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)
 *  230：Microbenchmark Suite
 *  325：Switch Expressions (Preview)  
    
 *  334：JVM Constants API
 *  340：One AArch64 Port, Not Two
 *  341：Default CDS Archives
 *  344：Abortable Mixed Collections for G1
 *  346：Promptly Return Unused Committed Memory from G1

首先值得关注的是 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 -\u0026gt; System.out.println(6);        case TUESDAY -\u0026gt; System.out.println(7);        case THURSDAY, SATURDAY -\u0026gt; System.out.println(8);        case WEDNESDAY -\u0026gt; System.out.println(9);}

更进一步，下面的表达式，为我们提供了优雅地表达特定场合计算逻辑的方式

int numLetters = switch (day) {       case MONDAY, FRIDAY, SUNDAY -\u0026gt; 6;       case TUESDAY -\u0026gt; 7;       case THURSDAY, SATURDAY -\u0026gt; 8;       case WEDNESDAY -\u0026gt; 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 在移动对象时，对象引用仍然可以访问。

![\\"\\"][8c7e82c8bebe0305a927a1d39e66f2f7.jpeg]

下面是 jbb15 benchmark 中，Shenandoah GC 相对于其他主流 GC 的表现，GC 暂停相比于 CMS 等选择有数量级程度的提高，对于 GC 暂停非常敏感的场景，价值还是很明显的，能够在 SLA 层面有显著提高。当然，这种对于低延迟的保证，也是以消耗 CPU 等计算资源为代价的，实际吞吐量表现也不是非常明朗，需要看企业的实际场景需求，并不是一个一劳永逸的解决方案。

![\\"\\"][c04f4bbc49b74088a5024b9ff98878eb.jpeg]

其他的一些特性，例如，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 大踏步前进的曙光！

[8c7e82c8bebe0305a927a1d39e66f2f7.jpeg]: /images/20220222/3fe9cb6182e245498dfc4e240a5f4800.png
[c04f4bbc49b74088a5024b9ff98878eb.jpeg]: /images/20220222/21ce252e05034ccfadc5b5f450332c97.png