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規範定義一個組織，以便根據須要隨源代碼一塊兒更新這些規範，並能夠輕鬆地將其包括在生成的「文檔」映像中。