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