Java 12 都发布了，你是不是还在用 JDK 8？

去年 3 月份我写了一篇文章，因为 Java 10 发布了。一年过去了，Java 12 都发布了，这种更新频率对于广大 Java 程序员来说，可以说是匪夷所思。二十多年了，Java 在编程语言领域仍然保持了一哥的地位，这个世界上使用 Java 语言编程的程序员可能是最多的，它的风格就一个字，稳。

不过最近 Java 大版本更新的速度确实让老程序员们吃惊。十九年前，也就是千禧年 2000，Sun 公司连续在 5 月份推出了 JKD1.3 和 1.4，按照现在的版本规则，也就是 Java 3 和 4。四年以后 Java 5 发布，那是 2004 年，这种发布节奏让程序员完全找不到节奏，以至于 Java 5 发布了一年多之后，大部分程序员还在使用 4。2006年 Java 6 发布了，程序员们在抱怨 Java 语法滞重繁琐发展缓慢的同时，开始期待 Java 两年发布一次大版本，希望这货能做个正常的有节奏的编程语言。

然而并没有。

下一个版本的更新我们等了五年，那时候很多人都产生了一种错觉，以为 Java 语言就此不更新了。

但是，自从 Oracle 更新了发布计划和频率之后，Java 开始变得「出走半生，归来变成骚年」，神经病一样连续把 Java 从 9 推到了 12。其他语言的程序员都很喜欢追新，有新版本，稳定一下情绪，不多久就开始采用。Java 是个另类，如果我没猜错的话，很多企业和互联网服务还在跑在 JDK 8 上，至少我的 Mac 上就是 java version “1.8.0_51"。

那我们是否该跟随 Java 的脚步升级呢？听一下极客时间专栏作者杨晓峰老师的解读，看看 Java 12 为我们带来了什么：

---

在 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;  caseTUESDAY:    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 8 么？说说你的看法。

今日推荐：如果你以为是 Java 专栏就错了。今天是 iOS 开发高手课优惠期最后一天，68 订阅。目前订阅人数即将破万。如果你是个移动开发工程师，建议学习，毕竟是大前端的时代。