Java 11 正式发布，带来ZGC、Http Client等重要特性！

Java 11 已经正式发布，官网下载：https://www.oracle.com/technetwork/java/javase/downloads/index.html 

我们知道，从 Java 9 开始，JDK 就采用了新的发布模型，每 6 个月发布一个新版本。每 3 年有一个长期支持版本（Long Term Support，LTS）。Java 8 就是一个 LTS 版本。而刚刚发布的 Java 11 也是如此。如果还没有升级到 Java 9，倒是可以考虑直接向 Java 11 迁移。

Java 11 一共包含 17 个 JEP（JDK Enhancement Proposals，JDK 增强提案）。

 

具体如下。

 

181: Nest-Based Access Control

---

 

基于嵌套的访问控制。

Java 11 引入了 nest 的概念，这是一个新的访问控制上下文（context），逻辑上处于同一代码实体中的类，尽管会被编译为不同的 class 文件，但是可以访问彼此的 private 成员，不再需要编译器插入辅助访问的桥方法。

 

309: Dynamic Class-File Constants

---

 

动态 class  文件常量。扩展了 Java class 文件格式，支持一种新的常量池形式：CONSTANT_Dynamic。

 

315: Improve Aarch64 Intrinsics

---

 

主要是针对 ARM Aarch64 架构的优化，比如提供优化的 sin、cos 等函数。

 

318: Epsilon: A No-Op Garbage Collector(Experimental)

---

 

无操作的垃圾收集器。Epsilon 是一个特殊的垃圾收集器，只处理内存分配，不负责回收。一旦堆耗尽，就关闭 JVM。

 

听上去这个收集器好像没什么意义。不过它还是有不少用处的。比如：

 

性能测试。GC 会影响性能，有了这么一个几乎什么都不干的 GC，我们可以过滤掉 GC 带来的影响因素。还有些性能因素不是 GC 引入的，比如编译器变换，利用 Epsilon GC，我们可以对比。就像生物学里做实验，我们可以用它做一个对照组。

 

另外还有内存压力测试、VM接口测试等。

 

320: Remove the Java EE and CORBA Modules

---

 

将 Java SE 9 中标记为废弃的 Java EE 和 CORBA 正式从 Java SE 平台中删除。

 

321: HTTP Client (Standard)

---

 

标准化了 JDK 9 中引入的 HTTP Client API。在 JDK 9 引入的这个功能，当时还处于孵化阶段，API 放在 jdk.incubtor 下。在 JDK 11 中，该 API 会放在 java.net.http 包中。通过 CompletableFutures 提供了非阻塞的请求响应语义。依赖 JDK 9 和 10 相关包的代码，在升级时需要修改导入的包名。

 

323: Local-Variable Syntax for Lambda Parameters

---

 

Lambda 参数的局部变量语法。Java 10 引入了局部变量的类型推导，比如

 

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

 

而 Lambda 表达式也可以利用隐式类型推导，如

 

(x, y) -> x.process(y) 

 

为了语法的一致性，Java 11 支持在 Lambda 中使用 var ：

 

(var x, var y) -> x.process(y) 

 

324: Key Agreement with Curve25519 and Curve448

---

 

使用 RFC 7748 中描述的 Curve25519 和 Curve448 实现了密钥协商机制。

 

327: Unicode 10

---

 

升级现有 API 支持 Unicode 10。Java SE 10 实现的是 Unicode 8.0。与 Java 10 相比，Java 11 多支持 16 018 个新字符，10 种新的文字类型。

 

328: Flight Recorder

---

 

Java Flight Recorder (JFR) 一直是 Oracle JDK 的一个商用功能，现在也开源放到了 JDK 中。它为 Java 提供了一个低开销的数据收集框架，可以帮助定位 Java 应用和 HotSpot JVM 的问题。

 

329: ChaCha20 and Poly1305 Cryptographic Algorithms

---

 

实现了 RFC 7539 中描述的 ChaCha20 和 ChaCha20-Poly1305 加密算法。

 

330: Launch Single-File Source-Code Programs

---

 

支持运行单个文件中的源代码。在刚学习 Java 或者编写小的工具程序时，我们一般要先用 javac 编译源文件，再用 java 命令运行。有了这个功能，我们可以直接用 java 命令运行源程序。就像这样：

 

java HelloWorld.java

 

331: Low-Overhead Heap Profiling

---

 

提供一种低成本的堆分析方式。

 

332: Transport Layer Security (TLS) 1.3

---

 

实现 Transport Layer Security (TLS) 协议的 1.3 版本。值得注意的是，该 JEP 的 Owner 范学雷老师是中国人，之前也曾在 QCon 大会上做过多次分享（http://2016.qconshanghai.com/speakers/202088/）。

 

333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

---

 

ZGC是一个可伸缩、低延迟的垃圾收集器。该特性目前还是实验性的，需要通过 XX:+UnlockExperimentalVMOptions 和 -XX:+UseZGC 选项开启。

 

它有这么几个目标：

 

• GC停顿时间不超过10毫秒。

• 可以处理很大范围的堆，小到几百兆，大到几个T。

• 与使用G1相比，吞吐量下降不超过15%。

• 为未来的GC特性以及利用 colored pointers 和 load barriers来优化奠定基础。

• 先支持Linux/x64平台。

 

其工作原理如下：

 

At a glance, ZGC is a concurrent, single-generation, region-based, NUMA-aware, compacting collector. Stop-the-world phases are limited to root scanning, so GC pause times do not increase with the size of the heap or the live set.

 

A core design principle/choice in ZGC is the use of load barriers in combination with colored object pointers (i.e., colored oops). This is what enables ZGC to do concurrent operations, such as object relocation, while Java application threads are running. From a Java thread's perspective, the act of loading a reference field in a Java object is subject to a load barrier. In addition to an object address, a colored object pointer contains information used by the load barrier to determine if some action needs to be taken before allowing a Java thread to use the pointer. For example, the object might have been relocated, in which case the load barrier will detect the situation and take appropriate action.

 

ZGC 的性能非常值得期待，不过因为目前还是实验特性，在生产环境中应用到底效果如何，还需要进一步验证。

 

335: Deprecate the Nashorn JavaScript Engine

---

 

废弃 Nashorn JavaScript 脚本引擎、API 和 jjs 工具。Nashorn 是在 JDK 8 中引入的，当时完整实现了 ECMAScript-262 5.1。不过随着 ECMAScript 的演进加快，Nashorn 维护越来越困难。

 

336: Deprecate the Pack200 Tools and API

---

 

废弃了 pack200 和 unpack200 工具，以及 java.util.jar 包中的 Pack200 API。

 

完整说明见 https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html