从 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<String>(); // infers ArrayList<String> var stream = list.stream(); // infers Stream<String>
这种语法只限于初始化过的本地变量和 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 似乎并没有包含重大新特性或性能改进。这是可以理解的,毕竟这是新发布周期下的第一个版本。
查看英文原文: Java 10 - The Story So Far
评论