JDK9（2017.09.21-2018.01.26）
功能特性
1、modularity System 模块系统
2、HTTP/2
3、JShell
4、不可变集合工厂方法
5、私有接口方法
6、HTML5风格的Java帮助文档
7、多版本兼容 JAR
8、统一 JVM 日志
9、java9的垃圾收集机制
10、I/O 流新特性
5、应用程序类数据共享
6、线程局部握手
7、删除本机头生成工具（javah）
8、其他Unicode语言标签扩展
9、备用内存设备上的堆分配
10、基于Java的实验性JIT编译器
11、根证书
12、基于时间的发行版本控制
功能介绍和使用
1、局部变量类型推断
对于开发者来说，这是 JDK10 唯一的真正特性。它向 Java 中引入在其他语言中很常见的var比如 Javascript 。只要编译器可以推断此种类型，你不再需要专门声明一个局部变量的类型。一个简单的例子是：
var x = new ArrayList<String>();
这就消除了我们之前必须执行的 ArrayList<String> 类型定义的重复。我鼓励你们去读 JEP ，因为上面有一些关于这个句法是否能用的规则。有趣的是，需要注意 var 不能成为一个关键字，而是一个保留字。这意味着你仍然可以使用 var 作为一个变量，方法或包名，但是现在（尽管我确定你绝不会）你不能再有一个类被调用。
2、将JDK森林整合到单个存储库中
在 JDK9 中，有 8 个仓库： root、corba、hotspot、jaxp、jaxws、jdk、langtools 和 nashorn 。在 JDK10 中这些将被合并为一个，使得跨相互依赖的变更集的存储库运行 atomic commit （原子提交）成为可能。
3、垃圾收集器接口
这不是让开发者用来控制垃圾回收的接口；而是一个在 JVM 源代码中的允许另外的垃圾回收器快速方便的集成的接口。
JEP 309: Dynamic Class-File Constants（动态类文件常量）
Java的类型文件格式将被拓展，支持一种新的常量池格式：CONSTANTDynamic，加载CONSTANTDynamic会将创建委托给bootstrap方法。其目标是降低开发新形式的可实现类文件约束带来的成本和干扰。
JEP 318：Epsilon：无操作垃圾收集器
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 320：删除Java EE和CORBA模块
Java EE和CORBA两个模块在JDK9中已经标记"deprecated"，在JDK11中正式移除。JDK中deprecated的意思是在不建议使用，在未来的release版本会被删除。
JEP 321：HTTP客户端（标准）
将JDK9引进并孵化的HTTP客户端API作为标准，即HTTP/2 Client。它定义了一个全新的实现了HTTP/2和WebSocket的HTTP客户端API，并且可以取代HttpURLConnection。 动机
已经存在的HttpURLConnection有如下问题:
在设计时考虑了多种协议，但是现在几乎所有协议现已不存在。
API早于HTTP/1.1并且太抽象；
使用很不友好；
只能以阻塞模式工作；
JEP 323：本地变量Lambda参数
在Lambda表达式中，可以使用var关键字来标识变量，变量类型由编译器自行推断。局部变量类型推断就是左边的类型直接使用 var 定义，而不用写具体的类型，编译器能根据右边的表达式自动推断类型。
import java.util.Arrays;public class LocalVar { public static void main(String[] args) { Arrays.asList("Java", "Python", "Ruby") .forEach((var s) -> { System.out.println("Hello, " + s); }); }}JEP 324的语法：与Curve25519和Curve448的密钥约定
用RFC 7748中描述到的 Curve25519 和Curve448 实现秘钥协议。RFC 7748定义的秘钥协商方案更高效，更安全。这个JEP的主要目标就是为这个标准定义API和实现。
动机
密码学要求使用 Curve25519 和Curve448 是因为它们的安全性和性能。JDK会增加两个新的接口XECPublicKey 和 XECPrivateKey，示例代码如下：
KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
kpg.initialize(paramSpec);
// equivalent to kpg.initialize(255)
// alternatively: kpg = KeyPairGenerator.getInstance("X25519")
KeyPair kp = kpg.generateKeyPair();
KeyFactory kf = KeyFactory.getInstance("XDH");
BigInteger u = ... XECPublicKeySpec
pubSpec = new XECPublicKeySpec(paramSpec, u);
PublicKey pubKey = kf.generatePublic(pubSpec);
KeyAgreement ka = KeyAgreement.getInstance("XDH");
ka.init(kp.getPrivate());
ka.doPhase(pubKey, true);
byte[] secret = ka.generateSecret();
JEP：Unicode 10
更新平台API支持Unicode 10.0版本（Unicode 10.0概述：Unicode 10.0 增加了8518 个字符, 总计达到了136,690个字符. 并且增加了4个脚本, 总结139个脚本, 同时还有56个新的emoji表情符号。参考：http://unicode.org/versions/Unicode10.0.0/）
JEP 328: 飞行记录器
提供一个低开销的，为了排错Java应用问题，以及JVM问题的数据收集框架，希望达到的目标如下：
提供用于生产和消费数据作为事件的API；
提供缓存机制和二进制数据格式；
允许事件配置和事件过滤；
提供OS，JVM和JDK库的事件；
动机
排错，监控，性能分析是整个开发生命周期必不可少的一部分，但是某些问题只会在大量真实数据压力下才会发生在生产环境。
Flight Recorder记录源自应用程序，JVM和OS的事件。 事件存储在一个文件中，该文件可以附加到错误报告中并由支持工程师进行检查，允许事后分析导致问题的时期内的问题。
JEP 329:ChaCha20 和 Poly1305 加密算法
实现RFC 7539中指定的 ChaCha20 和 ChaCha20-Poly1305 两种加密算法。业界一致认为当下ChaCha20-Poly1305是安全的。
JEP 331:低开销的 Heap Profilin
提供一种低开销的Java堆分配采样方法，得到堆分配的Java对象信息，可通过JVMTI访问。希望达到的目标如下：
足够低的开销，可以默认且一直开启；
能通过定义好的程序接口访问；
能采样所有分配；
能给出生存和死亡的Java对象信息； 动机
对用户来说，了解它们堆里的内存是很重要的需求。目前有一些已经开发的工具，允许用户窥探它们的堆，比如：Java Flight Recorder, jmap, YourKit, 以及VisualVM tools.。但是这工具都有一个很大的缺点：无法得到对象的分配位置。headp dump以及heap histo都没有这个信息，但是这个信息对于调试内存问题至关重要。因为它能告诉开发者，他们的代码发生（尤其是坏的）分配的确切位置。
JEP 332: 支持 TLS 1.3
实现TLS协议1.3版本。（TLS允许客户端和服务端通过互联网以一种防止窃听，篡改以及消息伪造的方式进行通信）
TLS 1.3是TLS协议的重大改进，与以前的版本相比，它提供了显着的安全性和性能改进。其他供应商的几个早期实现已经可用。我们需要支持TLS 1.3以保持竞争力并与最新标准保持同步。这个特性的实现动机和Unicode 10一样，也是紧跟历史潮流。
JEP 333: 可伸缩低延迟垃圾收集器
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 总结
1.11 版本是 Java 最新的长期支持版本，也将会是未来一段时间的主要版本，1.11 版本中提供的最激动人心的功能是 ZGC 这个新的垃圾回收器，ZGC 为大内存堆设计，有着非常强悍的性能，能够实现 10ms 以下的 GC 暂停时间。除此之外，1.11 版本对字符串处理 API 进行了增强，提供了字符复制等功能。1.11 版本还内置了 HttpClient，废弃了一些不安全的工具和API。
接下来将整理jdk12~jdk14的版本特性，欢迎捧场，来过就留下脚印~
