Java 10 新特性详解

从 Java 9 发布到现在已经过去两个月了，根据最新的发布计划，距离下一个 Java 版本发布只有四个月时间。Java 10 的新特性还在确认当中，所以从现在到 GA 版中间还是有可能加入重大的变更。不管怎样，在这四个月里，开发者还是可以期待一些新的特性能够被添加到 Java 10 中。

新的特性和增强一般通过 Java Enhancement Process(JEP)或 Java Community Process 标准请求(JSR)进行跟踪。因为 Java 10 的时间线较短，范围也相对较小，所以 Java 10 的变更将通过 JEP 进行跟踪。

有望被包含在 Java 10 中的特性是那些已经处于 Targeted 或 Proposed 状态的 JEP，它们包括：

286：本地变量类型推断 296：统一 JDK 仓库 304：垃圾回收器接口 307：G1 的并行 Full GC 310：应用程序类数据共享 312：ThreadLocal 握手机制

JEP 296 是一次纯粹的清理工作，而 JEP 304 加强了不同垃圾回收器的代码隔离，并为垃圾回收器引入更简洁的接口。

JEP 304 意味着厂商可以更自由地选择特定的 GC 算法来构建 JDK，因为现在有多种处于开发当中的 GC，如 Shenandoah、ZGC 和 Epsilon，在未来可以使用这些 GC 算法。社区也在努力弃用甚至移除 Concurrent Mark Sweep(CMS)垃圾回收器，只是目前还没有可用的替代品。

比较有意思的变更或许是 JEP 286，增强的本地变量类型推断可以让开发者免去很多变量申明模板代码。也就是说，在下一个版本中，下面的变量声明是合法的：

var list = new ArrayList(); // infers ArrayList

var stream = list.stream (); // infers Stream

这种语法只限于初始化过的本地变量和 for 循环中的本地变量。

它其实是个语法糖，在语义上并没有任何变化。不过，该特性有可能在 Java 开发者当中引起热议。

其他三个变更都将在性能方面带来一些影响。

JEP 307 解决了 G1 垃圾回收器的一个问题——截止到 Java 9，G1 的 Full GC 采用的是单线程算法。也就是说，G1 在发生 Full GC 时会严重影响性能。JEP 307 的目的就是要采用并行 GC 算法，在发生 Full GC 时可以使用多个线程进行并行回收。

JEP 310 对类数据共享(CDS)进行了扩展，JVM 可以将一些类记录到一个共享的压缩文件里，在 JVM 下一次启动时可以将这个文件映射到 JVM 进程，以此来减少启动时间。该文件也可以在多个 JVM 间共享，在同一个机器上运行多个 JVM 时，这样做可以减少内存占用。

该功能在 Java 5 中就已存在，但截止到 Java 9，该功能只允许 bootstrap 类加载器加载压缩的类。JEP 310 的目的是扩展该功能，让应用程序和自定义类加载器也能加载压缩的类。该特性目前仅在 Oracle JDK 中可用，OpenJDK 并不包含该特性。

JEP 计划将该特性从 Oracle 私有仓库中迁移到公共仓库，从 Java 10 往后，常规版本(非 LTS)将会使用 OpenJDK 的二进制包。此举表明有用户正在使用该特性，所以需要在 OpenJDK 中也支持该特性。

JEP 312 旨在改进虚拟机性能，在应用程序线程上调用回调不再需要执行全局虚拟机安全点操作，这意味着 JVM 可以停止单个线程。一些底层小改进包括：

降低堆栈跟踪取样所带来的影响(如进行 profiling)。 减少信号依赖以获得更好的堆栈取样。 通过停止单独线程改进偏向锁。 从 JVM 移除了一些内存屏障。

从整体来看，Java 10 似乎并没有包含重大新特性或性能改进。这是可以理解的，毕竟这是新发布周期下的第一个版本。