摘要：千呼萬喚，于正式發(fā)布版本即，也就是官方推薦可以廣泛使用的版本，其中發(fā)布了包括等個(gè)新特性，讓我們一睹為快。一新特性一覽二發(fā)布計(jì)劃日期階段說明對進(jìn)入階段的變化會(huì)應(yīng)用越來越嚴(yán)格的審查。我們需要支持以保持競爭力并與最新標(biāo)準(zhǔn)保持同步。

千呼萬喚，JDK11于2018-09-25正式發(fā)布GA版本(GA即General Availability，也就是官方推薦可以廣泛使用的版本)，其中發(fā)布了包括ZGC、Flight Recorder等17個(gè)新特性，讓我們一睹為快。

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

Java的類型文件格式將被拓展，支持一種新的常量池格式：CONSTANT_Dynamic，加載CONSTANT_Dynamic會(huì)將創(chuàng)建委托給bootstrap方法。

其目標(biāo)是降低開發(fā)新形式的可實(shí)現(xiàn)類文件約束帶來的成本和干擾。

JDK上對這個(gè)特性的描述是：開發(fā)一個(gè)處理內(nèi)存分配但不實(shí)現(xiàn)任何實(shí)際內(nèi)存回收機(jī)制的GC，一旦可用堆內(nèi)存用完，JVM就會(huì)退出。

如果有System.gc()的調(diào)用，實(shí)際上什么也不會(huì)發(fā)生（這種場景下和-XX:+DisableExplicitGC效果一樣），因?yàn)闆]有內(nèi)存回收，這個(gè)實(shí)現(xiàn)可能會(huì)警告用戶嘗試強(qiáng)制GC是徒勞。

用法非常簡單：

-XX:+UseEpsilonGC。

提供完全被動(dòng)的GC實(shí)現(xiàn)，具有有限的分配限制和盡可能低的延遲開銷，但代價(jià)是內(nèi)存占用和內(nèi)存吞吐量。

眾所周知，Java實(shí)現(xiàn)可廣泛選擇高度可配置的GC實(shí)現(xiàn)。 各種可用的收集器最終滿足不同的需求，即使它們的可配置性使它們的功能相交。 有時(shí)更容易維護(hù)多帶帶的實(shí)現(xiàn)，而不是在現(xiàn)有GC實(shí)現(xiàn)上堆積另一個(gè)配置選項(xiàng)。

它的主要用途如下：

性能測試（它可以幫助過濾掉GC引起的性能假象）；

內(nèi)存壓力測試（例如，知道測試用例應(yīng)該分配不超過1 GB的內(nèi)存，我們可以使用-Xmx1g配置-XX:+UseEpsilonGC，如果違反了該約束，則會(huì)heap dump并崩潰）；

非常短的JOB任務(wù)（對于這種任務(wù)，接受GC清理堆那都是浪費(fèi)空間）；

VM接口測試；

Last-drop 延遲&吞吐改進(jìn)；

Java EE和CORBA兩個(gè)模塊在JDK9中已經(jīng)標(biāo)記"deprecated"，在JDK11中正式移除。JDK中deprecated的意思是在不建議使用，在未來的release版本會(huì)被刪除。

JavaEE由4部分組成：

JAX-WS (Java API for XML-Based Web Services),

JAXB (Java Architecture for XML Binding)

JAF (the JavaBeans Activation Framework)

Common Annotations.

但是這個(gè)特性和JavaSE關(guān)系不大。并且JavaEE被維護(hù)在Github（https://github.com/javaee）中，版本同步造成維護(hù)困難。最后，JavaEE可以多帶帶引用，maven中心倉庫也提供了JavaEE（http://mvnrepository.com/arti...），所以沒必要把JavaEE包含到JavaSE中。

至于CORBA，使用Java中的CORBA開發(fā)程序沒有太大的興趣。因此，在JavaEE就把CORBA標(biāo)記為"Proposed Optional"，這就表明將來可能會(huì)放棄對這些技術(shù)的必要支持。

將JDK9引進(jìn)并孵化的HTTP客戶端API作為標(biāo)準(zhǔn)，即HTTP/2 Client。它定義了一個(gè)全新的實(shí)現(xiàn)了HTTP/2和WebSocket的HTTP客戶端API，并且可以取代HttpURLConnection。
動(dòng)機(jī)

已經(jīng)存在的HttpURLConnection有如下問題:

在設(shè)計(jì)時(shí)考慮了多種協(xié)議，但是現(xiàn)在幾乎所有協(xié)議現(xiàn)已不存在。

API早于HTTP/1.1并且太抽象；

使用很不友好；

只能以阻塞模式工作；

非常難維護(hù)；

在聲明隱式類型的lambda表達(dá)式的形參時(shí)允許使用var。

lamdba表達(dá)式可能是隱式類型的，它形參的所有類型全部靠推到出來的。隱式類型lambda表達(dá)式如下：

(x, y) -> x.process(y)

Java SE 10讓隱式類型變量可用于本地變量:

var foo = new Foo();
for (var foo : foos) { ... }
try (var foo = ...) { ... } catch ...

為了和本地變量保持一致，我們希望允許var作為隱式類型lambda表達(dá)式的形參：

(var x, var y) -> x.process(y) 

統(tǒng)一格式的一個(gè)好處就是modifiers和notably注解能被加在本地變量和lambda表達(dá)式的形參上，并且不會(huì)丟失簡潔性：

@Nonnull var x = new Foo();
(@Nonnull var x, @Nullable var y) -> x.process(y)

用RFC 7748中描述到的 Curve25519 和Curve448 實(shí)現(xiàn)秘鑰協(xié)議。RFC 7748定義的秘鑰協(xié)商方案更高效，更安全。這個(gè)JEP的主要目標(biāo)就是為這個(gè)標(biāo)準(zhǔn)定義API和實(shí)現(xiàn)。

密碼學(xué)要求使用 Curve25519 和Curve448 是因?yàn)樗鼈兊陌踩院托阅堋DK會(huì)增加兩個(gè)新的接口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();

更新平臺(tái)API支持Unicode 10.0版本（Unicode 10.0概述：Unicode 10.0 增加了8518 個(gè)字符, 總計(jì)達(dá)到了136,690個(gè)字符. 并且增加了4個(gè)腳本, 總結(jié)139個(gè)腳本, 同時(shí)還有56個(gè)新的emoji表情符號。參考：http://unicode.org/versions/U...）。

Unicode是一個(gè)不斷進(jìn)化的工業(yè)標(biāo)準(zhǔn)，因此必須不斷保持Java和Unicode最新版本同步。

提供一個(gè)低開銷的，為了排錯(cuò)Java應(yīng)用問題，以及JVM問題的數(shù)據(jù)收集框架，希望達(dá)到的目標(biāo)如下：

提供用于生產(chǎn)和消費(fèi)數(shù)據(jù)作為事件的API；

提供緩存機(jī)制和二進(jìn)制數(shù)據(jù)格式；

允許事件配置和事件過濾；

提供OS，JVM和JDK庫的事件；

排錯(cuò)，監(jiān)控，性能分析是整個(gè)開發(fā)生命周期必不可少的一部分，但是某些問題只會(huì)在大量真實(shí)數(shù)據(jù)壓力下才會(huì)發(fā)生在生產(chǎn)環(huán)境。

Flight Recorder記錄源自應(yīng)用程序，JVM和OS的事件。 事件存儲(chǔ)在一個(gè)文件中，該文件可以附加到錯(cuò)誤報(bào)告中并由支持工程師進(jìn)行檢查，允許事后分析導(dǎo)致問題的時(shí)期內(nèi)的問題。工具可以使用API從記錄文件中提取信息。

實(shí)現(xiàn)RFC 7539中指定的 ChaCha20 和 ChaCha20-Poly1305 兩種加密算法。

唯一一個(gè)其他廣泛采用的RC4長期以來一直被認(rèn)為是不安全的，業(yè)界一致認(rèn)為當(dāng)下ChaCha20-Poly1305是安全的。

增強(qiáng)Java啟動(dòng)器支持運(yùn)行單個(gè)Java源代碼文件的程序。

單文件程序是指整個(gè)程序只有一個(gè)源碼文件，通常是早期學(xué)習(xí)Java階段，或者寫一個(gè)小型工具類。以HelloWorld.java為例，運(yùn)行它之前需要先編譯。我們希望Java啟動(dòng)器能直接運(yùn)行這個(gè)源碼級的程序：

java HelloWorld.java

等價(jià)于：

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

等價(jià)于：

javac -d  Factorial.java
java -cp  Factorial 3 4 5

到JDK10為止，Java啟動(dòng)器能以三種方式運(yùn)行：

啟動(dòng)一個(gè)class文件；

啟動(dòng)一個(gè)JAR中的main方法類；

啟動(dòng)一個(gè)模塊中的main方法類；

JDK11再加一個(gè)，即第四種方式：啟動(dòng)一個(gè)源文件申明的類。

提供一種低開銷的Java堆分配采樣方法，得到堆分配的Java對象信息，可通過JVMTI訪問。希望達(dá)到的目標(biāo)如下：

足夠低的開銷，可以默認(rèn)且一直開啟；

能通過定義好的程序接口訪問；

能采樣所有分配；

能給出生存和死亡的Java對象信息；

動(dòng)機(jī)

對用戶來說，了解它們堆里的內(nèi)存是很重要的需求。目前有一些已經(jīng)開發(fā)的工具，允許用戶窺探它們的堆，比如：Java Flight Recorder, jmap, YourKit, 以及VisualVM tools.。但是這工具都有一個(gè)很大的缺點(diǎn)：無法得到對象的分配位置。headp dump以及heap histo都沒有這個(gè)信息，但是這個(gè)信息對于調(diào)試內(nèi)存問題至關(guān)重要。因?yàn)樗芨嬖V開發(fā)者，他們的代碼發(fā)生（尤其是壞的）分配的確切位置。

實(shí)現(xiàn)TLS協(xié)議1.3版本。（TLS允許客戶端和服務(wù)端通過互聯(lián)網(wǎng)以一種防止竊聽，篡改以及消息偽造的方式進(jìn)行通信）。

TLS 1.3是TLS協(xié)議的重大改進(jìn)，與以前的版本相比，它提供了顯著的安全性和性能改進(jìn)。其他供應(yīng)商的幾個(gè)早期實(shí)現(xiàn)已經(jīng)可用。我們需要支持TLS 1.3以保持競爭力并與最新標(biāo)準(zhǔn)保持同步。這個(gè)特性的實(shí)現(xiàn)動(dòng)機(jī)和Unicode 10一樣，也是緊跟歷史潮流。

ZGC：這應(yīng)該是JDK11最為矚目的特性，沒有之一。但是后面帶了Experimental，說明還不建議用到生產(chǎn)環(huán)境。看看官方對這個(gè)特性的目標(biāo)描述：

GC暫停時(shí)間不會(huì)超過10ms；

即能處理幾百兆小堆，也能處理幾個(gè)T的大堆（OMG）；

和G1相比，應(yīng)用吞吐能力不會(huì)下降超過15%；

為未來的GC功能和利用colord指針以及Load barriers優(yōu)化奠定基礎(chǔ)；

初始只支持64位系統(tǒng)；

GC是Java主要優(yōu)勢之一。然而，當(dāng)GC停頓太長，就會(huì)開始影響應(yīng)用的響應(yīng)時(shí)間。消除或者減少GC停頓時(shí)長，Java將對更廣泛的應(yīng)用場景是一個(gè)更有吸引力的平臺(tái)。此外，現(xiàn)代系統(tǒng)中可用內(nèi)存不斷增長， 用戶和程序員希望JVM能夠以高效的方式充分利用這些內(nèi)存，并且無需長時(shí)間的GC暫停時(shí)間。
ZGC一個(gè)并發(fā)，基于region，壓縮型的垃圾收集器，只有root掃描階段會(huì)STW，因此GC停頓時(shí)間不會(huì)隨著堆的增長和存活對象的增長而變長。
ZGC和G1停頓時(shí)間比較：

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

因?yàn)閆GC還處于實(shí)驗(yàn)階段，所以需要通過JVM參數(shù)UnlockExperimentalVMOptions 來解鎖這個(gè)特性。

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