Java 12 新特性

Java 12 已如期于 3 月 19 日正式发布，此次更新是 Java 11 这一长期支持版本发布之后的一次常规更新，截至目前，Java 半年为发布周期，并且不会跳票承诺的发布模式，已经成功运行一年多了。通过这样的方式，Java 开发团队能够将一些重要特性尽早的合并到 Java Release 版本中，以便快速得到开发者的反馈，避免出现类似 Java 9 发布时的两次延期的情况。

1 Switch 表达式

Java 12 早在 2018 年 12 月便进入了 Rampdown Phase One 阶段，这意味着该版本所有新的功能特性被冻结，不会再加入更多的 JEP。该阶段将持续大概一个月，主要修复 P1-P3 级错误。主要时间节点如下：

2018-12-13 Rampdown 第一阶段 ( 从主线分离 )
2019-01-17 Rampdown 第二阶段
2019-02-07 发布候选阶段
2019-03-19 正式发布

本文主要针对 Java 12 中的新特性展开介绍，让您快速了解 Java 12 带来的变化。

使用Java 12，switch不仅可以作为语句也可以作为表达式。无论作为语句或者作为表达式，switch都可以使用传统/简化的作用域和控制流行为。这将有助于简化代码，并为在switch中使用模式匹配铺平道路。

Java开发人员正在增强Java编程语言，以使用模式匹配来解决当前switch语句的几个问题。这包括：switch块的默认控制流行为，switch块默认作用域（被视为单个作用域的块）和switch仅作为语句。

在Java 11中，switch语句追随C和C++，默认情况下使用fall-through语义。虽然传统的控制流程在编写低级代码时很有用，但随着switch在更高级别的环境中采用，易出错会盖过其灵活性。

Java 11

Java 12

2 默认CDS归档

通过在64位平台上的默认类列表的帮助下生成CDS归档来改进JDK构建过程，从而有效地消除了运行java -Xshare：dump。此功能的目标包括：1。）改进开箱即用的启动时间，以及2.）摆脱使用-Xshare：dump。

3 Shenandoah GC

Shenandoah是一种垃圾收集（GC）算法，旨在保证低延迟（10 - 500 ms的下限）。它通过在运行Java工作线程的同时执行GC操作减少GC暂停时间。使用Shenandoah，暂停时间不依赖于堆的大小。这意味着无论堆的大小如何，暂停时间都是差不多的。

这是一个实验性功能，不包含在默认（Oracle）的OpenJDK版本中。

4 JMH 基准测试

此功能为JDK源代码添加了一套微基准测试（大约100个），简化了现有微基准测试的运行和新基准测试的创建过程。它基于Java Microbenchmark Harness（JMH）并支持JMH更新。

此功能使开发人员可以轻松运行当前的微基准测试并为JDK源代码添加新的微基准测试。可以基于Java Microbenchmark Harness（JMH）轻松测试JDK性能。它将支持JMH更新，并在套件中包含一组（约100个）基准测试。

5 JVM 常量 API

JEP 334引入了一个API，用于建模关键类文件和运行时artifacts，例如常量池。此API将包括ClassDesc，MethodTypeDesc，MethodHandleDesc和DynamicConstantDesc等类。此 API 对于操作类和方法的工具很有帮助。

6 G1的可中断 mixed GC

此功能通过将Mixed GC集拆分为强制部分和可选部分，使G1垃圾收集器更有效地中止垃圾收集过程。通过允许垃圾收集过程优先处理强制集，g1可以更多满足满足暂停时间目标。

G1是一个垃圾收集器，设计用于具有大量内存的多处理器机器。由于它提高了性能效率，g1垃圾收集器最终将取代cms垃圾收集器。

G1垃圾收集器的主要目标之一是满足用户设置的暂停时间。G1采用一个分析引擎来选择在收集期间要处理的工作量。此选择过程的结果是一组称为GC集的区域。一旦GC集建立并且GC已经开始，那么G1就无法停止。

如果G1发现GC集选择选择了错误的区域，它会将GC区域的拆分为两部分（强制部分和可选部分）来切换到处理Mix GC的增量模式。如果未达到暂停时间目标，则停止对可选部分的垃圾收集。

7 G1归还不使用的内存

此功能的主要目标是改进G1垃圾收集器，以便在不活动时将Java堆内存归还给操作系统。为实现此目标，G1将在低应用程序活动期间定期生成或持续循环检查完整的Java堆使用情况。

这将立即归还未使用的部分Java堆内存给操作系统。用户可以选择执行FULL GC以最大化返回的内存量。

8 移除多余ARM64实现

Java 12将只有一个ARM 64位实现（aarch64）。目标是删除所有与arm64实现相关的代码，同时保留32位ARM端口和64位aarch64实现。

这将把重点转移到单个64位ARM实现，并消除维护两个实现所需的重复工作。当前的JDK 11实现中有两个64位ARM实现。

Shenandoah：一个低停顿垃圾收集器（实验阶段）

Java 12 中引入一个新的垃圾收集器：Shenandoah，它是作为一中低停顿时间的垃圾收集器而引入到 Java 12 中的，其工作原理是通过与 Java 应用程序中的执行线程同时运行，用以执行其垃圾收集、内存回收任务，通过这种运行方式，给虚拟机带来短暂的停顿时间。

Shenandoah 垃圾回收器是 Red Hat 在 2014 年宣布进行的一项垃圾收集器研究项目，旨在针对 JVM 上的内存收回实现低停顿的需求。该设计将与应用程序线程并发，通过交换 CPU 并发周期和空间以改善停顿时间，使得垃圾回收器执行线程能够在 Java 线程运行时进行堆压缩，并且标记和整理能够同时进行，因此避免了在大多数 JVM 垃圾收集器中所遇到的问题。

据 Red Hat 研发 Shenandoah 团队对外宣称，Shenandoah 垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为 200 MB 还是 200 GB，都将拥有一致的系统暂停时间，不过实际使用性能将取决于实际工作堆的大小和工作负载。

Shenandoah GC

上图对应工作周期如下：

Init Mark 启动并发标记阶段
并发标记遍历堆阶段
并发标记完成阶段
并发整理回收无活动区域阶段
并发 Evacuation 整理内存区域阶段
Init Update Refs 更新引用初始化阶段
并发更新引用阶段
Final Update Refs 完成引用更新阶段
并发回收无引用区域阶段

需要了解不是唯有 GC 停顿可能导致常规应用程序响应时间比较长。具有较长的 GC 停顿时间会导致系统响应慢的问题，但响应时间慢并非一定是 GC 停顿时间长导致的，队列延迟、网络延迟、其他依赖服务延迟和操作提供调度程序抖动等都可能导致响应变慢。使用 Shenandoah 时需要全面了解系统运行情况，综合分析系统响应时间。各种 GC 工作负载对比如下所示：

图 2. 各种 GC 工作负载对比

Shenandoah