JDK11新特性解讀

千呼萬喚，JDK11於2018-09-25正式發佈GA版本(GA即General Availability，也就是官方推薦能夠普遍使用的版本)，其中發佈了包括ZGC、Flight Recorder等17個新特性，讓咱們一睹爲快。

1、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

2、JDK11發佈計劃

日期	階段	說明
2018/06/28	Rampdown Phase One (fork from main line)	對進入Rampdown階段的變化會應用愈來愈嚴格的審查。在階段1中，只能修復 P1-P3 錯誤。
2018/07/26	Rampdown Phase Two	在階段2中，只能修復 showstopper 錯誤
2018/08/16	Initial Release Candidate
2018/08/30	Final Release Candidate	在此階段必須宣佈最終候選版的發佈日期並提交以進行測試
2018/09/25	General Availability	最終版本，可在生產環境正式使用

3、JDK11特性解讀

JEP 181: Nest-Based Access Control（基於嵌套的訪問控制）

JEP 309: Dynamic Class-File Constants（動態類文件常量）

Java的類型文件格式將被拓展，支持一種新的常量池格式：CONSTANT_Dynamic，加載CONSTANT_Dynamic會將建立委託給bootstrap方法。

目標

其目標是下降開發新形式的可實現類文件約束帶來的成本和干擾。

JEP 315: Improve Aarch64 Intrinsics（改進 Aarch64 函數）

JEP 318: Epsilon: A No-Op Garbage Collector（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: Remove the Java EE and CORBA Modules（刪除 Java EE 和 CORBA 模塊）

Java EE和CORBA兩個模塊在JDK9中已經標記"deprecated"，在JDK11中正式移除。JDK中deprecated的意思是在不建議使用，在將來的release版本會被刪除。

動機

JavaEE由4部分組成：

• JAX-WS (Java API for XML-Based Web Services),
• JAXB (Java Architecture for XML Binding)
• JAF (the JavaBeans Activation Framework)
• Common Annotations.

可是這個特性和JavaSE關係不大。而且JavaEE被維護在Github（https://github.com/javaee）中，版本同步形成維護困難。最後，JavaEE能夠單獨引用，maven中心倉庫也提供了JavaEE（http://mvnrepository.com/arti...），因此不必把JavaEE包含到JavaSE中。

至於CORBA，使用Java中的CORBA開發程序沒有太大的興趣。所以，在JavaEE就把CORBA標記爲"Proposed Optional"，這就代表未來可能會放棄對這些技術的必要支持。

JEP 321: HTTP Client (Standard)（標準HTTP客戶端）

將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 參數的局部變量語法）

在聲明隱式類型的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 324: Key Agreement with Curve25519 and Curve448（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 327: Unicode 10

更新平臺API支持Unicode 10.0版本（Unicode 10.0概述：Unicode 10.0 增長了8518 個字符, 總計達到了136,690個字符. 而且增長了4個腳本, 總結139個腳本, 同時還有56個新的emoji表情符號。參考：http://unicode.org/versions/U...）。

動機

Unicode是一個不斷進化的工業標準，所以必須不斷保持Java和Unicode最新版本同步。

JEP 328: Flight Recorder（飛行記錄器）

提供一個低開銷的，爲了排錯Java應用問題，以及JVM問題的數據收集框架，但願達到的目標以下：

• 提供用於生產和消費數據做爲事件的API；
• 提供緩存機制和二進制數據格式；
• 容許事件配置和事件過濾；
• 提供OS，JVM和JDK庫的事件；

動機

排錯，監控，性能分析是整個開發生命週期必不可少的一部分，可是某些問題只會在大量真實數據壓力下才會發生在生產環境。

Flight Recorder記錄源自應用程序，JVM和OS的事件。 事件存儲在一個文件中，該文件能夠附加到錯誤報告中並由支持工程師進行檢查，容許過後分析致使問題的時期內的問題。工具可使用API從記錄文件中提取信息。

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms（ChaCha20 和 Poly1305 加密算法）

實現RFC 7539中指定的 ChaCha20 和 ChaCha20-Poly1305 兩種加密算法。

動機

惟一一個其餘普遍採用的RC4長期以來一直被認爲是不安全的，業界一致認爲當下ChaCha20-Poly1305是安全的。

JEP 330: Launch Single-File Source-Code Programs（啓動單一文件的源代碼程序）

加強Java啓動器支持運行單個Java源代碼文件的程序。

動機

單文件程序是指整個程序只有一個源碼文件，一般是早期學習Java階段，或者寫一個小型工具類。以HelloWorld.java爲例，運行它以前須要先編譯。咱們但願Java啓動器能直接運行這個源碼級的程序：

java HelloWorld.java

等價於：

javac -d <memory> HelloWorld.java
java -cp <memory> helloWorld
java Factorial.java 3 4 5

等價於：

javac -d <memory> Factorial.java
java -cp <memory> Factorial 3 4 5

到JDK10爲止，Java啓動器能以三種方式運行：

1. 啓動一個class文件；
2. 啓動一個JAR中的main方法類；
3. 啓動一個模塊中的main方法類；

JDK11再加一個，即第四種方式：啓動一個源文件申明的類。

JEP 331: Low-Overhead Heap Profiling（低開銷的 Heap Profiling）

提供一種低開銷的Java堆分配採樣方法，獲得堆分配的Java對象信息，可經過JVMTI訪問。但願達到的目標以下：

• 足夠低的開銷，能夠默認且一直開啓；
• 能經過定義好的程序接口訪問；
• 能採樣全部分配；
• 能給出生存和死亡的Java對象信息；

動機

對用戶來講，瞭解它們堆裏的內存是很重要的需求。目前有一些已經開發的工具，容許用戶窺探它們的堆，好比：Java Flight Recorder, jmap, YourKit, 以及VisualVM tools.。可是這工具都有一個很大的缺點：沒法獲得對象的分配位置。headp dump以及heap histo都沒有這個信息，可是這個信息對於調試內存問題相當重要。由於它能告訴開發者，他們的代碼發生（尤爲是壞的）分配的確切位置。

JEP 332: Transport Layer Security (TLS) 1.3（支持 TLS 1.3）

實現TLS協議1.3版本。（TLS容許客戶端和服務端經過互聯網以一種防止竊聽，篡改以及消息僞造的方式進行通訊）。

動機

TLS 1.3是TLS協議的重大改進，與之前的版本相比，它提供了顯着的安全性和性能改進。其餘供應商的幾個早期實現已經可用。咱們須要支持TLS 1.3以保持競爭力並與最新標準保持同步。這個特性的實現動機和Unicode 10同樣，也是緊跟歷史潮流。

JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (可伸縮低延遲垃圾收集器)

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 來解鎖這個特性。

JEP 335: Deprecate the Nashorn JavaScript Engine（棄用 Nashorn JavaScript 引擎）

JEP 336: Deprecate the Pack200 Tools and API（棄用 Pack200 工具和 API）

參考: http://openjdk.java.net/proje...