Java 10 新特性解密，引入类型推断机制

发布于 2017-12-11 00:59:59 | 260 次阅读 | 评论: 0 | 来源: 网友投递

这里有新鲜出炉的Java并发编程示例，程序狗速度看过来！

Java程序设计语言

随着Java开发工具包(JDK)9的发布，大量的注意力都集中在Java的最新特性上，包括引入模块(通过集成项目Jigsaw)。尽管最近的很多关注都集中在这些强大的新功能上，但下一个版本的Java:JDK 10已经开始准备了。在本文中，我们将粗略地介绍一下JDK 10的主要特性，并探讨JDK 10中可能包含的一些特性。

请注意，本文中所包含的信息在写本文时是准确的。但是到发布时，JDK 10特性组预计将会增加。

新功能

与之前的JDK版本一样，对于即将到来的JDK 10也有一些主要特性。这些特性可以分为两个主要类别:(1)目标发布，(2)建议发布。前者表示某些特性已计划在JDK 10中发布，后一种类型表示这些特性还需要增加支持和成熟度。一旦条件允许，它就可以升级为一个目标发布状态。

目标发布

目前有两个主要功能针对JDK 10:

• 局部变量类型推断,这将删除大部分对象实例化所需的冗长的包含手动类型信息

• 整合源树source tree的JDK库,即不同的JDK库将被合并成一个单一的存储库。

1. 局部变量类型推断

强类型编程语言有很多优点，包括在编译时发现类型错误，但是它们也引入了大量的样板代码，特别是在定义局部变量时。例如，当我们希望实例化一个对象时，我们被迫在赋值的左侧提供显式类型，并在赋值的右边提供实现类型，如下面的片段所示:

MyObject value = new MyObject();

但是，当这个过程重复出现大量任务时，对象实例化可能变得令人沮丧和乏味。许多最流行的强类型的编程语言,比如C++, C#以及Go,在定义过程中，提供一种局部变量类型推断的功能(例如C++提供了auto 关键字，C#提供var关键字)。但是，Java仍缺乏这样的功能,它要求开发人员显式声明变量的预期清单类型。

为了解决这个问题,Java开发工具包(JDK)改进建议(JEP)286提出了一个上下文敏感的关键字var，允许局部变量被以下方式初始化：

var value = new MyObject();  var list = new ArrayList<MyObject>();

由于var关键字是上下文敏感的，它的使用有下面的规则定义:

代码使用var作为一个变量、方法或包名称时将不受影响;而使用var作为类或接口名称的代码将受到影响。

同样，类型推断将受到以下方式的约束：

推断类型将被限制在局部变量的初始化,增强的for循环索引,以及传统的for循环中声明;它(将)不用于方法形式、构造函数形式、方法返回类型、字段、捕获形式，或任何其他类型的变量声明。

考虑到所有的限制和细微差别，这个特性将有助于在开发人员创建的应用程序Java代码中减轻大量的单调无聊的动作，并简化JDK代码库。更多信息可以在官方的JEP 286规范中找到。

2. 整合的JDK库

目前，有8个不同的Mercurial存储库用于存储包含JDK的大量源代码:

• root

• corba

• hotspot

• jaxp

• jaxws

• JDK

• langtools

• nashorn

虽然过多的存储库提供了对组成JDK的各种组件并清晰分离，但管理多个存储库存在一些主要的缺点。

其中最重要的一点是，在JDK的两个不同部分，单个错误修复程序不能被原子跟踪。例如，如果一个bug修复需要对独立存储库中包含的系统的两个部分进行更改，那么必须提交两个提交:每个存储库中一个。这种不连续性很容易地降低项目和源代码管理工具的可跟踪性和复杂性。

为了解决这个问题，JEP 296建议将所有现有存储库合并到一个Mercurial存储库中。这种合并的一个次生效应是，这个单一的Mercurial存储库比现有的8个存储库要更容易的被镜像(作为一个Git存储库)。

虽然在这个整合过程中，外部开发人员有一些阻力，但是JDK开发团队似乎已经致力于使这一更改成为JDK 10的一部分。有关更多信息，请参见JEP 296，并提议整合由Michael Redlich发布的JDK 10 OpenJDK Mercurial存储库声明。

建议发布

除了两个目标特性之外，JDK 10目前还有三个建议，其中两个主要是对JDK的垃圾收集器部分进行升级，另一个侧重于对JDK的本地线程功能进行升级。

1 .清理垃圾收集接口

在当前的JDK结构中，组成垃圾收集器(GC)实现的组件分散在代码库的各个部分。尽管这些惯例对于使用GC计划的JDK开发者比较熟悉，但对新的开发人员来说，对于特定GC的源代码，或者创建一个新的GC常常会感到困惑。更重要的是，随着Java modules的出现，我们希望在构建过程中排除不需要的GC，但是GC接口的当前横切结构排除了这种增强。

JEP 304被设计为解决此问题的方案，并建议整合并清理GC接口，以便更容易地实现新的GC，并更好地维护现有的GC。本建议完成后，GC执行将负责提供以下内容:

•  heap，CollectedHeap的子类

•  barrier set，BarrierSet的子类，它实现了运行时的各种障碍

•  一个CollectorPolicy的实现

•  GCInterpreterSupport的实现，它实现了解释器的GC的各种障碍(使用汇编指令)

•  GCC1Support的实现，它为C1编译器实现了GC的各种障碍

•  GCC2Support的实现，它为C2编译器实现了GC的各种障碍

•  最终GC特定参数的初始化

•  设置MemoryService、相关的内存池、内存管理器等。

有关这些更改的更多信息，请参见JEP 304规范;有关Java GC的更多信息，请参阅Oracle提供的垃圾收集器基础指南。

2. G1垃圾收集器并行化

随着JDK 9的发布，Garbage-First(G1)GC取代了Parallel Collector作为默认GC。为了减少JDK 9之外的JDK版本中垃圾收集的影响，G1收集器将被并行化(以匹配并行收集器的特征)。虽然目前还没有关于这个并行化的实现细节的信息，但是可以在JEP 307规范中找到关于此更改的更多细节。

有关GC实现的更多信息，请参阅Oracle的G1指南和并行收集器指南。

3. 项目线程局部握手

当前，停止Java线程是一个“全部或没有”的过程，需要一个Java虚拟机(JVM)的安全点，以使一个线程停止。为了让单独的线程停止，JEP 312提议将回调包含到线程中。这一更改受到了限制，因为它显著地提高了现有JVM功能的性能开销，并且改变了到达JVM全局安全点的现有时间语义。有关这个建议的更多信息，请参阅JEP 312的Thread-Local Handshake OpenJDK讨论。

结论

尽管JDK 9对于许多Java开发人员非常新鲜，但它的发展并没有停止。特别是，JDK 10承诺为局部变量实例化引入类型推断机制，并将现有的JDK存储库合并到一个Mercurial存储库中。

此外，在更成熟和更支持的情况下，JDK 10还可能包括一些重要的升级到GC接口和默认的GC实现，以及升级到JVM中单个线程的可寻址能力。虽然JDK 10的发布在未来仍然相对较远，而且包含的特性很可能会成为Java时间轴上的一个重要里程碑。