Java9新特性逐项解析，总有一项get到你的点
一、JDK 与 JRE 的关系
JDK :JavaDevelopmentKit (Java开发工具包)
JRE :JavaRuntimeEnvironment (Java运行环境)
说明：
JDK = JRE + 开发工具集（例如Javac编译工具等）
JRE = JVM + Java SE标准类库
二、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类和资源文件。
三、JDK 9 的目录结构
说明：
没有名为jre的子目录
bin 目录包含所有命令。 在Windows平台上，它继续包含系统的运行时动态链接库。
conf 目录包含用户可编辑的配置文件，例如以前位于jrelib目录中的.properties和.policy文件
include 目录包含要在以前编译本地代码时使用的C/C++头文件。 它只存在于JDK中
jmods 目录包含JMOD格式的平台模块。 创建自定义运行时映像时需要它。 它只存在于JDK中
legal 目录包含法律声明
lib 目录包含非Windows平台上的动态链接本地库。 其子目录和文件不应由开发人员直接编辑或使用
四、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 V8、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/article/details/54580038
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规范定义一个组织，以便根据需要随源代码一起更新这些规范，并可以轻松地将其包括在生成的“文档”映像中。
推荐相关文章：
《Java8最值得学习的新特性：Lambda，Stream API》
《java9 150多项新特性，大改版，内附源码，实战解析，收藏！》
参考：
http://www.infoq.com/cn/articles/is-java-out-of-date
http://blog.csdn.net/hj7jay/article/details/54580038