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

\u003cblockquote\u003e\n\u003cp\u003eJava 12 如约而至，除了那些值得关注的特性，你也应该思考下 Java 的未来。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e在 Java 9 之前，当一个版本被宣布为首选版本，存在一个“培育”（bedded-in）新 GA 版本的重叠期。在此期间，上一个版本将会继续进行免费更新。为确保新旧版本间的干净切换，即便旧版本已不再是首选版本，通常也会继续维护 12 个月以上。但是随着 Java 版本发布更改为遵循严格的时间表后，事实上宣告了传统的免费支持期将寿终正寝。\u003c/p\u003e\n\u003cp\u003eOracle 对 Java 8 的官方支持时间持续到 2020 年 12 月，之后将不再为个人桌面用户提供 Oracle JDK 8 的修复更新；在 2019 年 1 月之后，不再提供免费的商业版本更新，届时想要继续获得 Oracle 的商业支持和维护，需付费订阅。\u003c/p\u003e\n\u003cp\u003eJava 是很多程序员的饭碗，Java 生态圈下的程序员们似乎对于 Oracle 也有诸多不满，当 Java 也像 Android 系统走上版本号的稳定道路后，新版本的发布意义还有那么大吗？Java 12 已经发布了，但使用版本最多的还是 Java 8，你会选择升级吗？\u003c/p\u003e\n\u003chr /\u003e\n\u003cp\u003eJDK12 如期而至，不知不觉 Java 半年为周期的发布模式（Half-year-cadence）已经成功运行了一年多，OpenJDK 社区和 Oracle 充分展示了其坚决的执行力。今天当然要尝鲜 JDK12 的新特性，与此同时，笔者也会从不同角度，来分析新发布模式是否达到了其初衷。\u003c/p\u003e\n\u003cp\u003e下载地址：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.oracle.com/technetwork/java/javase/downloads/index.html\"\u003ehttps://www.oracle.com/technetwork/java/javase/downloads/index.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eJDK 12 新特性一览：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/189\"\u003e189：Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/230\"\u003e230：Microbenchmark Suite\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/325\"\u003e325：Switch Expressions (Preview)\u003cbr /\u003e\n\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/334\"\u003e334：JVM Constants API\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/340\"\u003e340：One AArch64 Port, Not Two\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/341\"\u003e341：Default CDS Archives\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/344\"\u003e344：Abortable Mixed Collections for G1\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"http://openjdk.java.net/jeps/346\"\u003e346：Promptly Return Unused Committed Memory from G1\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e首先值得关注的是 Switch Expressions，这是一个为开发者准备的特性，我们可以利用具体代码快速了解一下，下面是传统 statement 形式的 switch 语法：\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eswitch(day){\n case MONDAY:\n case FRIDAY:\n case SUNDAY:\n System.out.println(6);\n break;\n case TUESDAY:\n System.out.println(7);\n break;\n case THURSDAY:\n case SATURDAY:\n System.out.println(8);\n break;\n case WEDNESDAY:\n System.out.println(9);\n break;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e如果有编码经验，你一定知道，switch 语句如果漏写了一个 break，那么逻辑往往就跑偏了，这种方式既繁琐，又容易出错。如果换成 switch 表达式，Pattern Matching 机制能够自然地保证只有单一路径会被执行，请看下面的代码示例：\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eswitch (day) {\n case MONDAY, FRIDAY, SUNDAY -\u0026gt; System.out.println(6);\n case TUESDAY -\u0026gt; System.out.println(7);\n case THURSDAY, SATURDAY -\u0026gt; System.out.println(8);\n case WEDNESDAY -\u0026gt; System.out.println(9);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e更进一步，下面的表达式，为我们提供了优雅地表达特定场合计算逻辑的方式\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eint numLetters = switch (day) {\n case MONDAY, FRIDAY, SUNDAY -\u0026gt; 6;\n case TUESDAY -\u0026gt; 7;\n case THURSDAY, SATURDAY -\u0026gt; 8;\n case WEDNESDAY -\u0026gt; 9;\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSwitch Expressions 或者说起相关的 Pattern Matching 特性，为我们提供了勾勒出了 Java 语法进化的一个趋势，将开发者从复杂繁琐的低层次抽象中逐渐解放出来，以更高层次更优雅的抽象，既降低代码量，又避免意外编程错误的出现，进而提高代码质量和开发效率。\u003c/p\u003e\n\u003cp\u003e第二，则是很有现实意义度 Shenandoah GC。它是 Redhat 主导开发的 Pauseless GC 实现，从大概 2013 年开始研发，终于取得了重要的阶段性成果，与其他 Pauseless GC 类似，Shenandoah GC 主要目标是 99.9% 的暂停小于 10ms，暂停与堆大小无关等。\u003c/p\u003e\n\u003cp\u003e也许了解 Shenandoah GC 的人比较少，业界声音比较响亮的是 Oracle 在 JDK11 中开源出来的 ZGC，或者商业版本的 Azul C4（Continuously Concurrent Compacting Collector）。但是，笔者认为，至少目前，其实际意义大于后两者，因为：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e使用 ZGC 的最低门槛是升级到 JDK11，对很多团队来说，这种版本的跳跃并不是非常低成本的事情，更何况是尚不清楚 ZGC 在自身业务场景中的实际表现如何。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e而 C4，毕竟是土豪们的选择，现实情况是，有多少公司连个几十块钱的 License 都不舍得…\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e而 Shenandoah GC 可是有稳定的 JDK8u 版本发布的哦，据我所知已经有个别公司在 HBase 等高实时性产品中实践许久。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e从原理的角度，我们可以参考该项目官方的示意图，其内存结构与 G1 非常相似，都是将内存划分为类似棋盘的 region。整体流程与 G1 也是比较相似的，最大的区别在于实现了并发的 Evacuation 环节，引入的 Brooks Forwarding Pointer 技术使得 GC 在移动对象时，对象引用仍然可以访问。\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://static001.geekbang.org/resource/image/8c/f7/8c7e82c8bebe0305a927a1d39e66f2f7.jpeg\" alt=\"\" /\u003e\u003c/p\u003e\n\u003cp\u003e下面是 jbb15 benchmark 中，Shenandoah GC 相对于其他主流 GC 的表现，GC 暂停相比于 CMS 等选择有数量级程度的提高，对于 GC 暂停非常敏感的场景，价值还是很明显的，能够在 SLA 层面有显著提高。当然，这种对于低延迟的保证，也是以消耗 CPU 等计算资源为代价的，实际吞吐量表现也不是非常明朗，需要看企业的实际场景需求，并不是一个一劳永逸的解决方案。\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://static001.geekbang.org/resource/image/c0/eb/c04f4bbc49b74088a5024b9ff98878eb.jpeg\" alt=\"\" /\u003e\u003c/p\u003e\n\u003cp\u003e其他的一些特性，例如，G1 相关的两个特性是对 G1 在特定场景不足的有效改进，但谈不上是突破性的提高，不再一一列举。\u003c/p\u003e\n\u003cp\u003e与 JDK11 这种长期支持版本（Long-Term-Support，LTS）相比，JDK12 似乎关注度有限，大家对于 JDK 这种频繁的节奏也有点麻木了，那么\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eJDK12 这种非 LTS 版本，是否有什么生产环境价值？\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eJava 新的发布模式是否达到了其快速落地和迭代新特性的目的？\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e也许不会有太多公司直接选择 JDK12，但个别的生产实践并不遥远。比如，我所在部门在实践场景中发现，利用 JDK 12 的 Abortable Mixed Collections for G1，解决了 HDFS 在特定场景中 G1 Evacuation 时间过长的困扰，虽然最后团队选择将其 backport 到了自己的 JDK11 版本中，但如果没有快速交付的预览版 JDK12，也不会如此快速的得到结论。\u003c/p\u003e\n\u003cp\u003e而对另一个问题，笔者认为目前看是非常成功的，解开了 Java/JVM 演进的许多枷锁，至关重要的是，OpenJDK 的权力中心，正在转移到开发社区和开发者手中。在新的模式中，既可以利用 LTS 满足企业长期可靠支持的需求，也可以满足各种开发者对于新特性迭代的诉求。你可能注意到了 Switch Expressions 被打上了预览（Preview）的标签，Shenandoah GC 则是实验（Experimental）特性，这些都是以往的发布周期下不大现实的，因为用 2-3 年的最小间隔粒度来实验一个特性，基本是不现实的。\u003c/p\u003e\n\u003cp\u003e可以预计，JDK8 在未来的一段时间仍将是主流，我们已经注意到 Amazon、Alibaba、Redhat、AdoptOpenJDK 等等厂商或社区，纷纷发布了自己的 JDK8 等产品，开始竞赛长期支持版本 JDK 的主导权，笔者认为这是非常好的迹象，反映了主流厂商对于 Java 的投资力度增大。\u003c/p\u003e\n\u003cp\u003e是否会带来 Java/JVM 的碎片化呢？多少会发生一些，但从目前的合作模式来看，OpenJDK 仍然是合作的中心，主导这 Java 历史版本维护和未来的演进路线。\u003c/p\u003e\n\u003cp\u003e一些小鲜肉语言嘲笑 Java，实现类似功能，Java 代码要多写近一倍，程序要笨重一个数量级，有些也许是言过其实，但语法的表达能力和 JVM 的庞大，确实逐渐成为 Java 发展的短板，JDK10～12 发布的不间断成功，让我们看到了 Java/JVM 大踏步前进的曙光！\u003c/p\u003e\n