Java9新特性逐项解析

1、JDK 与 JRE 的关系
JDK :JavaDevelopmentKit (Java开发工具包)
JRE :JavaRuntimeEnvironment (Java运行环境)

说明：
JDK = JRE + 开发工具集（例如Javac编译工具等）
JRE = JVM + Java SE标准类库
2、JDK 8 的目录结构

说明：
bin 目录包含命令行开发和调试工具，如javac，jar和javadoc。
include目录包含在编译本地代码时使用的C/C++头文件
lib 目录包含JDK工具的几个JAR和其余类型的文件。 它有一个tools.jar文件，其中包含javac编译器的Java类
jre/bin 目录包含基本命令，如java命令。 在Windows平台上，它包含系统的运行时动态连接库（DLL）。
jre/lib 目录包含用户可编辑的配置文件，如.properties和.policy文件。包含几个JAR。 rt.jar文件包含运行时的Java类和资源文件。
3、JDK 9 的目录结构

说明：
没有名为jre的子目录
bin 目录包含全部命令。 在Windows平台上，它继续包含系统的运行时动态连接库。
conf 目录包含用户可编辑的配置文件，例如之前位于jrelib目录中的.properties和.policy文件
include 目录包含要在之前编译本地代码时使用的C/C++头文件。 它只存在于JDK中
jmods 目录包含JMOD格式的平台模块。 建立自定义运行时映像时须要它。 它只存在于JDK中
legal 目录包含法律声明
lib 目录包含非Windows平台上的动态连接本地库。 其子目录和文件不该由开发人员直接编辑或使用
4、Java9新增特性：

102: Process API Updates
进程操做API 升级，提高对操做系统进程的控制和管理。
新增的
java.lang.ProcessHandle
类丰富了对进程的操做，同时原有的
java.lang.Process
类的功能也被增强了。
在Java很早的版本中，提供了Process这样的API能够得到进程的一些信息，包括runtime，甚至是用它来执行当前主机的一些命令，可是请你们思考一个问题，你如何得到你当前Java运行程序的PID？很显然经过Process是没法得到的，须要借助于JMX才能获得，可是在这一次的加强中，你将会很轻松的获得这样的信息，咱们来看一个简单的例子：

上面有大量的Optional，这是Java 8中的API，一样在Java 9中对其进行了加强。
已经获取到了JVM的进程，咱们该如何将该进程优雅的停掉呢？下面的代码给出了答案

110: HTTP 2 Client
就目前而言，JDK提供的Http访问功能，几乎都须要依赖于HttpURLConnection，可是这个类你们在写代码的时候不多使用，咱们通常都会选择Apache的Http Client，这次在Java 9的版本中引入了一个新的package:java.net.http，里面提供了对Http访问很好的支持，不只支持Http1.1并且还支持HTTP2，以及WebSocket，听说性能能够超过Apache HttpClient，Netty，Jetty，简单的来看一个代码片断：

经过上面的一小段代码，咱们也发现了Java 9对断言机制一样增长了一些加强，多说一些题外话，咱们目前的系统中运行一个严重依赖于Hive beelineServer的程序，beeline server不是很稳定，常常出现卡顿，甚至假死，假死后也不回复的问题，这样就致使咱们的程序也会出现卡顿，若是运维人员不对其进行清理，系统运行几个月以后会发现不少僵尸进程，因而增长一个获取当前JVM PID的功能，而后判断到超过给定的时间对其进行主动杀死，彻底是程序内部的行为，可是获取PID就必须借助于JMX的动做，另外杀死它也必须借助于操做系统的命令，诸如kill这样的命令，显得很是的麻烦，可是Java 9的方式明显要优雅方便许多。
143: Improve Contended Locking
优化竞争锁的性能
可以改善程序运行时的多线程同步效率。
158: Unified JVM Logging
统一 JVM 日志
日志是解决问题的惟一有效途径：曾经很难知道致使JVM性能问题和致使JVM崩溃的根本缘由。不一样的JVM日志的碎片化和日志选项（例如：JVM组件对于日志使用的是不一样的机制和规则），这使得JVM难以进行调试。
解决该问题最佳方法：对全部的JVM组件引入一个单一的系统，这些JVM组件支持细粒度的和易配置的JVM日志
165: Compiler Control
193: Variable Handles
操做内存，用来替代sun.misc.Unsafe。操做内存更安全，且性能相同或类似的等效sun.misc.unsafe操做。
在JDK 9中提供了一个新的包，叫作java.lang.invoke里面有一系列很重要的类好比VarHandler和MethodHandles，提供了相似于原子操做以及Unsafe操做的功能。
197: Segmented Code Cache
代码分段缓存
Java 9的另外一个性能提高来自于JIT(Just-in-time)编译器。当某段代码被大量重复执行的时候, 虚拟机会把这段代码编译成机器码(native code)并储存在代码缓存里面, 继而经过访问缓存中不一样分段的代码来提高编译器的效率。代码分段缓存机制将会提高许多方面的性能，如当JVM进行垃圾回收扫描的时候，就能够直接跳过永驻代码,从而提高效率
JDK 9 中的代码段在 Segmented Code Cache 的做用下，能够被更加细分，并且每一个代码段还能够包括特定类型的编译代码，这个功能一样也有望提高 Java 9 性能。
这个特性通常不会在 Java 代码中直接使用，它经过对本地编译代码（即代码缓存）进行更好的组织，让 JRE 的运行效率有所提升。
198: Light-Weight JSON API
尽管目前有多种处理JSON的Java工具（如Google的Gson、阿里巴巴的FastJson、IBM的Json4J等），但JSON API是Java语言的一部分，轻量而且运用了Java 8的新特性。JSON API将放在java.util包里一块儿发布，这样，开发者就能够直接使用JDK而无需再引入第三方JSON工具包了
199: Smart Java Compilation, Phase Two
改进sjavac工具的稳定性和可移植性，使其能够更好地用于大型项目的构建。
智能Java编译工具（sjavac）的第一阶段始于JEP139这个项目, 用于在多核处理器状况下提高JDK的编译速度。现在，这个项目已经进入第二阶段即JEP199, 其目的是改进Java编译工具，并取代目前JDK编译工具javac，继而成为Java环境默认的通用的智能编译工具
200: The Modular JDK
Java 9中最重要的功能，毫无疑问就是模块化（Module），代码名字叫作Jigsaw(拉锯），这个拉锯项目拉了几年，终于要把庞大冗余的Java锯成一个个的Module，方便开发和部署。熟悉Java的同窗，都知道JRE有一个超级大rt.jar（例如，Java 8的rt.jar中有65M），运行一个hello world，你也须要一个数百兆的JRE环境，若是在J2EE环境，状况将变得复杂无比
201: Modular Source Code
211: Elide Deprecation Warnings on Import Statements
212: Resolve Lint and Doclint Warnings
213: Milling Project Coin
接口的私有方法
Java 8中规定接口中的方法除了抽象方法以外，还能够定义静态方法和默认的方法。必定程度上，扩展了接口的功能，此时的接口更像是一个抽象类。
在Java 9中，接口更加的灵活和强大，连方法的访问权限修饰符均可以声明为private的了，此时方法将不会成为你对外暴露的API的一部分。
214: Remove GC Combinations Deprecated in JDK 8
215: Tiered Attribution for javac
216: Process Import Statements Correctly
217: Annotations Pipeline 2.0
219: Datagram Transport Layer Security (DTLS)
220: Modular Run-Time Images
模块化运行时镜像
221: Simplified Doclet API
222: jshell: The Java Shell (Read-Eval-Print Loop)
交互式命令行
简称 JShell，方便对程序进行调试，以及快速检验 API 的可行性无须无须建立一个项目来学习 API，打开 JShell 便可。
在Java 8 出来的时候，不少人都喊着，这是要抢夺Scala等基于JVM动态语言的市场啊，其中有人给出了一个Java作不到的方向，那就是Scala能够看成脚本语言，Java能够么？很明显在此以前Java不行，ta也不具有动态性，可是这次Java 9 却让Java也能够像脚本语言同样来运行了，主要得益于JShell，咱们来看一下这个演示

这是咱们在Jshell这个控制台下运行，咱们如何运行脚本文件呢？

223: New Version-String Scheme
224: HTML5 Javadoc
jdk 8 ：生成的java帮助文档是在HTML 4 中，而HTML 4 已是好久的标准了。
jdk 9 ：javadoc的输出，如今符合兼容HTML 5 标准。
下图是java8 中生成的html页面，若是想要找到一些类文档，必须在google中搜索

下图是在java 9 中，添加了一个搜索框。

225: Javadoc Search
226: UTF-8 Property Files
属性文件支持 UTF-8 编码
ResourceBundle 的缺省编码问题一直是被吐槽的对象，非英文字符被转码为看不懂的形式，严重损害了代码的可读性。从 Java 9 开始，ResourceBundle 默认编码为 UTF-8。
227: Unicode 7.0
JDK9升级现有的平台APIs以支持Unicode标准的7.0版，支持Unicode的最新版本。
228: Add More Diagnostic Commands
229: Create PKCS12 Keystores by Default
231: Remove Launch-Time JRE Version Selection
232: Improve Secure Application Performance
233: Generate Run-Time Compiler Tests Automatically
235: Test Class-File Attributes Generated by javac
236: Parser API for Nashorn
JDK 9 中附带了一个 Nashorn 的 parser API，它的目标是 Java 在本地 JVM 中实现轻量级高性能 JS runtime。这个新特性能够保障 Java 9 更好的融合 JavaScript 和 Java 的两方之力。
237: Linux/AArch64 Port
链接到Linux / AArch64的端口。
AArch64是ARM控股公司推出的新处理器体系结构。它与32位ARM处理器架构不一样，其实是一个彻底的从新设计。它须要一个新的OpenJDK端口
238: Multi-Release JAR Files
当一个新版本的Java出现的时候，你的库用户要花费数年时间才会切换到这个新的版本。这就意味着库得去向后兼容你想要支持的最老的Java版本（许多状况下就是Java 6 或者 Java7）。这实际上意味着将来的很长一段时间，你都不能在库中运用Java 9所提供的新特性。幸运的是，多版本兼容jar功能能让你建立仅在特定版本的Java环境中运行库程序选择使用的class版本。
240: Remove the JVM TI hprof Agent
从JDK中删除高性能代理。
J2SE中提供了一个简单的命令行工具来对java程序的cpu和heap进行 profiling，叫作HPROF。HPROF其实是JVM中的一个native的库。该工具已被更好的替代品所取代。
241: Remove the jhat Tool
删除过期的jhat工具。
jhat是在JDK 6中基于Java . net帽子项目添加的。jhat是一个实验性的、不受支持的、过期的工具。高级堆可视化工具和分析器已经使用多年。
243: Java-Level JVM Compiler Interface
动态编译器
对于整个编程语言的发展，可能都具备很是重要的意义，虽然未必引发了普遍关注。目前 Graal Core API 已经被集成进入 Java 9，虽然还只是初始一小步，可是彻底用 Java 语言来实现的可靠的、高性能的动态编译器，彷佛再也不是高不可攀。
244: TLS Application-Layer Protocol Negotiation Extension
245: Validate JVM Command-Line Flag Arguments
246: Leverage CPU Instructions for GHASH and RSA
247: Compile for Older Platform Versions
248: Make G1 the Default Garbage Collector
G1 成为默认的垃圾收集器
G1 进一步减小了 GC 时的停顿时间（GC pause time），其实它从 JDK 8u40 开始就已经十分完善，足以做为默认的垃圾收集器了。
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
接口java.awt.image.MultiResolutionImage封装了一系列的不一样分辨率图像到一个单独对象的API，我么能够根据给定的DPI 矩阵获取resolution-specific,看一下下面的代码片断:

252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
优化字符串占用空间
在不少应用当中，字符串已经成为一个消耗内存的主要部分。经过优化字符串的占用空间，应用的内存使用能够获得明显改善。
255: Merge Selected Xerces 2.11.0 Updates into JAXP
256: BeanInfo Annotations
257: Update JavaFX/Media to Newer Version of GStreamer
258: HarfBuzz Font-Layout Engine
259: Stack-Walking API
260: Encapsulate Most Internal APIs
261: Module System
Java 模块化-重大特性
该项目主要的目的是为更小的设备提供可伸缩性，改进 JDK 和 Java SE 的安全性，对大型应用的性能提高以及更易于构建。这个功能会使 JDK、run-time images 以及 Java 源代码等模块化，甚至开发者还能够建立本身的模块来简化代码
262: TIFF Image I/O
263: HiDPI Graphics on Windows and Linux
264: Platform Logging API and Service
265: Marlin Graphics Renderer
266: More Concurrency Updates
267: Unicode 8.0
268: XML Catalogs
269: Convenience Factory Methods for Collections
集合工厂方法：快速建立只读集合
270: Reserved Stack Areas for Critical Sections
271: Unified GC Logging
该特性为JVM的全部组件引入了一个通用的日志系统，提供了JVM日志的基础设施，你能够不用专门为了打印某些日志而添加一些专门的标签，只须要使用统一的log指令便可，好比：

272: Platform-Specific Desktop Features
273: DRBG-Based SecureRandom Implementations
274: Enhanced Method Handles
275: Modular Java Application Packaging
276: Dynamic Linking of Language-Defined Object Models
277: Enhanced Deprecation
278: Additional Tests for Humongous Objects in G1
G1中大量对象的附加测试
279: Improve Test-Failure Troubleshooting
自动收集诊断信息，以便在测试失败和超时的状况下进一步排除故障。
280: Indify String Concatenation
281: HotSpot C++ Unit-Test Framework
282: jlink: The Java Linker
Java链接器
链接器负责高层会话，如http会话。链接器框架组件，基于NIO开发，用于javaiis http服务器项目。

284: New HotSpot Build System
使用构建基础架构重写热点构建系统。
本项目的目标是用一个新的、简化得多的基于build - infra框架的构建系统替换当前的构建系统。更具体地说:
利用build - infra框架中提供的功能，最大限度地减小代码重复。
简化热点构建系统以提供更易于维护的代码库，并下降阈值以供未来改进。
285: Spin-Wait Hints
定义API以容许Java代码提示正在执行旋转循环，即自旋等待提示。
定义一个API，容许Java代码提示运行时系统它处于旋转循环中。API将是一个纯提示，不包含语义行为需求(例如，无操做是有效的实现)。容许JVM受益于在某些硬件平台上可能有用的自旋循环特定行为。在JDK中提供无操做实现和固有实现，并在至少一个主要硬件平台上演示执行优点。
287: SHA-3 Hash Algorithms
实现NIST FIPS 202中指定的SHA - 3加密散列函数(仅字节)。
SHA - 2发布于10多年前，虽然还没有证实对SHA - 2的重大攻击，但NIST认为须要一种不一样的加密散列函数来替代SHA - 2。九年来，SHA - 3是NIST利用公开竞争和审查过程开发的第一个加密哈希算法。FIPS 202 " SHA - 3标准:基于排列的散列和可扩展输出函数"于2015年8月做为标准定稿。当FIPS 202仍是草稿时，诸如BouncyCastle之类的加密供应商开始支持SHA - 3。Solaris还将在即将发布的Solaris 12.0版本中支持SHA - 3。因为哈希函数在安全应用程序中普遍使用，而且其余供应商已经添加了SHA - 3实现，所以在JDK中为SHA - 3提供支持很是重要。
288: Disable SHA-1 Certificates
经过提供更灵活的机制来禁用具备基于SHA - 1签名的x . 509证书链，改进了JDK的安全配置。
目标不是禁用SHA - 1证书的全部用法。只有经过CertPathValidator和CertPathBuilder API的PKIX实现以及TrustManagerFactory API的SunX509和PKIX实现验证的X.509证书链才受限制。其余用途(解析等)。)中的证书不受影响。CertPathValidator、CertPathBuilder和TrustManagerFactory的第三方实现直接负责实施它们本身的限制。
基于SHA - 1的数字签名算法的使用因为冲突攻击的风险而日益成为安全问题。NIST在SP 800 - 57第1部分中建议再也不使用SHA - 1对数据应用数字签名。CA / Browser论坛对公众信任的SSL证书的基线要求规定，自2016年1月1日起，证书颁发机构不得使用SHA - 1颁发任何从属CA或订户证书。其余软件供应商(谷歌、微软、Mozilla、苹果)已经公布了在证书中对SHA - 1进行贬值的计划。在JDK中，x . 509证书链用于验证TLS中的服务器和客户端以及验证签名代码的完整性和做者
289: Deprecate the Applet API
Applet API 被标记为为过期。

要在web浏览器中运行Java小程序，须要使用浏览器插件。然而，截至2015年末，许多浏览器供应商要么已经取消了插件支持，要么宣布了取消插件支持的时间表。一旦浏览器插件消失，就没有理由使用Applet API。
290: Filter Incoming Serialization Data
291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector
Java 9 或将放弃 CMS（并发标记清除垃圾收集器）
取消对CMS的支持，而后删除CMS代码，或者至少更完全地分离CMS代码，将减小GC代码库的维护负担，并加快新的开发。从长远来看，G1垃圾收集器将取代CMS的大多数用途。
新版本未指定将删除CMS支持的主要版本。什么时候执行此操做，取决于G1收集器在多大程度上被证实是CMS的合适替代品。同时，鼓励CMS用户迁移到G1收集器( - XX : + UseG1GC )。
可是从经验来看，不少 Java 应用选择的是 CMS+ParNew，并且不少应用针对 CMS 的行为作了优化。如今宣布去掉 CMS，或许还为时过早。
292: Implement Selected ECMAScript 6 Features in Nashorn
ECMAScript 6于2015年6月发布。到目前为止，尚未一个JavaScript引擎提供对ES6的完整支持，可是包括Google V八、Mozilla蜘蛛猴和JavaScript core在内的主要引擎最近在实现ES6方面取得了重大进展。
Nashorn 项目在 JDK 9 中获得改进，它为 Java 提供轻量级的 Javascript 运行时。Nashorn 项目跟随 Netscape 的 Rhino 项目，目的是为了在 Java 中实现一个高性能但轻量级的 Javascript 运行时。Nashorn 项目使得 Java 应用可以嵌入 Javascript。它在 JDK 8 中为 Java 提供一个 Javascript 引擎。
JDK 9 包含一个用来解析Nashorn 的ECMAScript 语法树的API。这个 API 使得 IDE 和服务端框架不须要依赖 Nashorn 项目的内部实现类，就可以分析 ECMAScript 代码。
294: Linux/s390x Port
s390x (也称为“系统z”或“z /体系结构”)是由IBM开发和支持的大型机体系结构。包括Ubuntu、RHEL / Fedora和SuSE在内的几个Linux发行版在s390上运行。
目前的云部署，包括TomEE、Cassandra、Spark、Hadoop和Neo4j等软件包，严重依赖Java。由于大多数软件包都是开源的，因此它们在OpenJDK上运行得最好，而OpenJDK目前对Linux / s390x不可用。

目前，零端口可用于在Linux / s390x上运行JDK，但速度很慢(由于它只使用旧的、弃用的c++解释器)，而且测试不太好。它不是运行应用程序服务器或用Java编写的数据库应用程序等工做负载的真正替代方案。
IBM的Linux开发工具包也可用于Linux / s390x，但它目前不是开源的，Java应用程序一般须要一些配置/调优才能与它一块儿运行。此外，它不能用于测试即将发布的Java版本的新功能，由于它仅在JDK自己是GA以后发布。
SAP有一个完整的(即模板解释器、C1和C2 JIT )和通过认证的( Java SE 1.4 - 8 ) s390x端口，已在生产中使用多年。
295: Ahead-of-Time Compilation
AOT 编译
JIT（Just-in-time）编译器能够在运行时将热点编译成本地代码，速度很快。可是 Java 项目如今变得很大很复杂，所以 JIT 编译器须要花费较长时间才能热身完，并且有些 Java 方法还无法编译，性能方面也会降低。AoT 编译就是为了解决这些问题而生的。
AOT 编译做为实验特性被引入进来，开发者能够利用新的 jaotc 工具将重点代码转换成相似类库同样的文件，这样会大大下降启动开销。
这个功能使得 Java 应用在被虚拟机启动以前可以先将 Java 类编译为原生代码。此功能旨在改进小型和大型应用程序的启动时间，同时对峰值性能的影响很小。
该功能目前仍处于试验阶段，但愿java10能有一个更稳定的版本。
jaotc详见：http://blog.csdn.net/hj7jay/a...
297: Unified arm32/arm64 Port
arm 32和arm 64的统一热点端口集成到JDK中。

为arm 32和arm 64提供了C1和C2支持,使其与其余体系结构保持一致。代码已合并到aarch32项目区域中单独存储库中的JDK 9树中。Oracle打算开放ARM端口的消息已于2016年8月23日在aarch 32邮件列表中公布，而且aarch 32邮件列表中有几个讨论线索。298: Remove Demos and Samples删除过期和未维护的演示和示例，其目的不是建立新的或替换的演示和示例。JDK / src / demo和JDK / src / sample中的大多数现有演示和示例都已过期且未维护，所以对处理JDK自己的开发人员或更普遍的Java社区都再也不有用。它们的源代码再也不表明Java编程语言和Java SE平台的最新使用状况，也没有更新它们的计划。更好的示例代码能够从许多其余来源得到，例如在更普遍的社区中发布的许多文章、书籍和演示文稿中299: Reorganize Documentation从新组织JDK文档的结构，包括源存储库和生成的文档。目标为生成的“文档”映像正式定义一个组织，包括API规范、手册页(可视为工具规范)和其余JDK规范。将javadoc工具生成的当前20多组文档合并到JDK映像的单个API规范集合中。为源存储库中存在的非API规范定义一个组织，以便根据须要随源代码一块儿更新这些规范，并能够轻松地将其包括在生成的“文档”映像中。