java 11 新特性

JDK11特性一览

181: Nest-Based Access Control
309: Dynamic Class-File Constants
315: Improve Aarch64 Intrinsics
318: Epsilon: A No-Op Garbage Collector
320: Remove the Java EE and CORBA Modules
321: HTTP Client (Standard)
323: Local-Variable Syntax for Lambda Parameters
324: Key Agreement with Curve25519 and Curve448
327: Unicode 10
328: Flight Recorder
329: ChaCha20 and Poly1305 Cryptographic Algorithms
330: Launch Single-File Source-Code Programs
331: Low-Overhead Heap Profiling
332: Transport Layer Security (TLS) 1.3
333: ZGC: A Scalable Low-Latency Garbage Collector
   (Experimental)
335: Deprecate the Nashorn JavaScript Engine
336: Deprecate the Pack200 Tools and API

 

JEP 318: Epsilon: A No-Op Garbage Collector

JDK上对这个特性的描述是：开发一个处理内存分配但不实现任何实际内存回收机制的GC，一旦可用堆内存用完，JVM就会退出。

若是有System.gc()的调用，实际上什么也不会发生（这种场景下和-XX:+DisableExplicitGC效果同样），由于没有内存回收，这个实现可能会警告用户尝试强制GC是徒劳。

用法很是简单：-XX:+UseEpsilonGC。

动机

提供彻底被动的GC实现，具备有限的分配限制和尽量低的延迟开销，但代价是内存占用和内存吞吐量。

众所周知，Java实现可普遍选择高度可配置的GC实现。 各类可用的收集器最终知足不一样的需求，即便它们的可配置性使它们的功能相交。 有时更容易维护单独的实现，而不是在现有GC实现上堆积另外一个配置选项。

它的主要用途以下：

• 性能测试（它能够帮助过滤掉GC引发的性能假象）；

• 内存压力测试（例如，知道测试用例应该分配不超过1 GB的内存，咱们可使用-Xmx1g配置-XX:+UseEpsilonGC，若是违反了该约束，则会heap dump并崩溃）；

• 很是短的JOB任务（对于这种任务，接受GC清理堆那都是浪费空间）；

• VM接口测试；

• Last-drop 延迟&吞吐改进；

 

 

JEP 321: HTTP Client (Standard)

将JDK9引进并孵化的HTTP客户端API做为标准，即HTTP/2 Client。它定义了一个全新的实现了HTTP/2和WebSocket的HTTP客户端API，而且能够取代HttpURLConnection。

动机

已经存在的HttpURLConnection有以下问题:

• 在设计时考虑了多种协议，可是如今几乎全部协议现已不存在。

• API早于HTTP/1.1而且太抽象；

• 使用很不友好；

• 只能以阻塞模式工做；

• 很是难维护；

•  

JEP 323: Local-Variable Syntax for Lambda Parameters

在声明隐式类型的lambda表达式的形参时容许使用var。

动机

lamdba表达式多是隐式类型的，它形参的全部类型所有靠推到出来的。隐式类型lambda表达式以下：

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

Java SE 10让隐式类型变量可用于本地变量:

var foo = new Foo();
for (var foo : foos) { ... }
try (var foo = ...) { ... } catch ...

为了和本地变量保持一致，咱们但愿容许var做为隐式类型lambda表达式的形参：

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

统一格式的一个好处就是modifiers和notably注解能被加在本地变量和lambda表达式的形参上，而且不会丢失简洁性：

@Nonnull var x = new Foo();
(@Nonnull var x, @Nullable var y) -> x.process(y)

 

JEP 328: Flight Recorder

提供一个低开销的，为了排错Java应用问题，以及JVM问题的数据收集框架，但愿达到的目标以下：

• 提供用于生产和消费数据做为事件的API；

• 提供缓存机制和二进制数据格式；

• 容许事件配置和事件过滤；

• 提供OS，JVM和JDK库的事件；

动机

排错，监控，性能分析是整个开发生命周期必不可少的一部分，可是某些问题只会在大量真实数据压力下才会发生在生产环境。

Flight Recorder记录源自应用程序，JVM和OS的事件。 事件存储在一个文件中，该文件能够附加到错误报告中并由支持工程师进行检查，容许过后分析致使问题的时期内的问题。工具可使用API从记录文件中提取信息。

多说一句：Flight Recorder的名字来源有点像来自于飞机的黑盒子，一种用来记录飞机飞行状况的的仪器。而Flight Recorder就是记录Java程序运行状况的工具。

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

实现RFC 7539中指定的 ChaCha20 和 ChaCha20-Poly1305 两种加密算法。

动机

惟一一个其余普遍采用的RC4长期以来一直被认为是不安全的，业界一致认为当下ChaCha20-Poly1305是安全的。

 

 

JEP 331: Low-Overhead Heap Profiling

提供一种低开销的Java堆分配采样方法，获得堆分配的Java对象信息，可经过JVMTI访问。但愿达到的目标以下：

• 足够低的开销，能够默认且一直开启；

• 能经过定义好的程序接口访问；

• 能采样全部分配；

• 能给出生存和死亡的Java对象信息；

动机

对用户来讲，了解它们堆里的内存是很重要的需求。目前有一些已经开发的工具，容许用户窥探它们的堆，好比：Java Flight Recorder, jmap, YourKit, 以及VisualVM tools.。可是这工具都有一个很大的缺点：没法获得对象的分配位置。headp dump以及heap histo都没有这个信息，可是这个信息对于调试内存问题相当重要。由于它能告诉开发者，他们的代码发生（尤为是坏的）分配的确切位置。

 

 

 

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

ZGC：这应该是JDK11最为瞩目的特性，没有之一。可是后面带了Experimental，说明还不建议用到生产环境。看看官方对这个特性的目标描述：

• GC暂停时间不会超过10ms；

• 即能处理几百兆小堆，也能处理几个T的大堆（OMG）；

• 和G1相比，应用吞吐能力不会降低超过15%；

• 为将来的GC功能和利用colord指针以及Load barriers优化奠基基础；

• 初始只支持64位系统；

动机

GC是Java主要优点之一。然而，当GC停顿太长，就会开始影响应用的响应时间。消除或者减小GC停顿时长，Java将对更普遍的应用场景是一个更有吸引力的平台。此外，现代系统中可用内存不断增加， 用户和程序员但愿JVM可以以高效的方式充分利用这些内存，而且无需长时间的GC暂停时间。

ZGC一个并发，基于region，压缩型的垃圾收集器，只有root扫描阶段会STW，所以GC停顿时间不会随着堆的增加和存活对象的增加而变长。

ZGC和G1停顿时间比较：

ZGC
                avg: 1.091ms (+/-0.215ms)
    95th percentile: 1.380ms
    99th percentile: 1.512ms
  99.9th percentile: 1.663ms
 99.99th percentile: 1.681ms
                max: 1.681ms

G1
                avg: 156.806ms (+/-71.126ms)
    95th percentile: 316.672ms
    99th percentile: 428.095ms
  99.9th percentile: 543.846ms
 99.99th percentile: 543.846ms
                max: 543.846ms

用法：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC，由于ZGC还处于实验阶段，因此须要经过JVM参数UnlockExperimentalVMOptions 来解锁这个特性。

 

 

参考：http://openjdk.java.net/projects/jdk/11/