重磅:JDK11正式發(fā)布!史上最全所有特性完整解讀!

千呼萬(wàn)喚,JDK11于2018-09-25正式發(fā)布!你是不是和筆者一樣還在使用JDK8呢?甚至有些開發(fā)者還在使用JDK7!沒關(guān)系,讓我們先一睹JDK11的風(fēng)采。

JDK11發(fā)布計(jì)劃

2018/06/28 Rampdown Phase One (fork from main line)
2018/07/19 All Tests Run
2018/07/26 Rampdown Phase Two
2018/08/16 Initial Release Candidate
2018/08/30 Final Release Candidate
2018/09/25 General Availability

說(shuō)明:GA即General Availability,也就是官方推薦可以廣泛使用的版本。

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

特性詳解

接下來(lái)對(duì)每個(gè)特性進(jìn)行詳細(xì)解讀。

JEP 318: Epsilon: A No-Op Garbage Collector

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

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

用法非常簡(jiǎn)單:-XX:+UseEpsilonGC。


動(dòng)機(jī)

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

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

它的主要用途如下:

  • 性能測(cè)試(它可以幫助過(guò)濾掉GC引起的性能假象);
  • 內(nèi)存壓力測(cè)試(例如,知道測(cè)試用例應(yīng)該分配不超過(guò)1 GB的內(nèi)存,我們可以使用-Xmx1g配置-XX:+UseEpsilonGC,如果違反了該約束,則會(huì)heap dump并崩潰);
  • 非常短的JOB任務(wù)(對(duì)于這種任務(wù),接受GC清理堆那都是浪費(fèi)空間);
  • VM接口測(cè)試;
  • Last-drop 延遲&吞吐改進(jìn);

JEP 320: Remove the Java EE and CORBA Modules

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


動(dòng)機(jī)

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可以單獨(dú)引用,maven中心倉(cāng)庫(kù)也提供了JavaEE(http://mvnrepository.com/artifact/javax/javaee-api/8.0),所以沒必要把JavaEE包含到JavaSE中。

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

JEP 321: HTTP Client (Standard)

將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有如下問(wèn)題:

  • 在設(shè)計(jì)時(shí)考慮了多種協(xié)議,但是現(xiàn)在幾乎所有協(xié)議現(xiàn)已不存在。
  • API早于HTTP/1.1并且太抽象;
  • 使用很不友好;
  • 只能以阻塞模式工作;
  • 非常難維護(hù);

JEP 323: Local-Variable Syntax for Lambda Parameters

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


動(dòng)機(jī)

lamdba表達(dá)式可能是隱式類型的,它形參的所有類型全部靠推到出來(lái)的。隱式類型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ì)丟失簡(jiǎn)潔性:

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

JEP 324: Key Agreement with Curve25519 and Curve448

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


動(dòng)機(jī)

密碼學(xué)要求使用 Curve25519 和Curve448 是因?yàn)樗鼈兊陌踩院托阅?。JDK會(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();

JEP 327: Unicode 10

更新平臺(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表情符號(hào)。參考:http://unicode.org/versions/Unicode10.0.0/)。


動(dòng)機(jī)

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

JEP 328: Flight Recorder

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

  • 提供用于生產(chǎn)和消費(fèi)數(shù)據(jù)作為事件的API;
  • 提供緩存機(jī)制和二進(jìn)制數(shù)據(jù)格式;
  • 允許事件配置和事件過(guò)濾;
  • 提供OS,JVM和JDK庫(kù)的事件;

動(dòng)機(jī)

排錯(cuò),監(jiān)控,性能分析是整個(gè)開發(fā)生命周期必不可少的一部分,但是某些問(wèn)題只會(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)致問(wèn)題的時(shí)期內(nèi)的問(wèn)題。工具可以使用API從記錄文件中提取信息。

多說(shuō)一句:Flight Recorder的名字來(lái)源有點(diǎn)像來(lái)自于飛機(jī)的黑盒子,一種用來(lái)記錄飛機(jī)飛行情況的的儀器。而Flight Recorder就是記錄Java程序運(yùn)行情況的工具。

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

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


動(dòng)機(jī)

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

JEP 330: Launch Single-File Source-Code Programs

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


動(dòng)機(jī)

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

java HelloWorld.java

等價(jià)于:

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

等價(jià)于:

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

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

  1. 啟動(dòng)一個(gè)class文件;
  2. 啟動(dòng)一個(gè)JAR中的main方法類;
  3. 啟動(dòng)一個(gè)模塊中的main方法類;

JDK11再加一個(gè),即第四種方式:?jiǎn)?dòng)一個(gè)源文件申明的類。

JEP 331: Low-Overhead Heap Profiling

提供一種低開銷的Java堆分配采樣方法,得到堆分配的Java對(duì)象信息,可通過(guò)JVMTI訪問(wèn)。希望達(dá)到的目標(biāo)如下:

  • 足夠低的開銷,可以默認(rèn)且一直開啟;
  • 能通過(guò)定義好的程序接口訪問(wèn);
  • 能采樣所有分配;
  • 能給出生存和死亡的Java對(duì)象信息;

動(dòng)機(jī)

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

JEP 332: Transport Layer Security (TLS) 1.3

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


動(dòng)機(jī)

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

JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

ZGC:這應(yīng)該是JDK11最為矚目的特性,沒有之一。但是后面帶了Experimental,說(shuō)明還不建議用到生產(chǎn)環(huán)境??纯垂俜綄?duì)這個(gè)特性的目標(biāo)描述:

  • GC暫停時(shí)間不會(huì)超過(guò)10ms;
  • 即能處理幾百兆小堆,也能處理幾個(gè)T的大堆(OMG);
  • 和G1相比,應(yīng)用吞吐能力不會(huì)下降超過(guò)15%;
  • 為未來(lái)的GC功能和利用colord指針以及Load barriers優(yōu)化奠定基礎(chǔ);
  • 初始只支持64位系統(tǒng);

動(dòng)機(jī)

GC是Java主要優(yōu)勢(shì)之一。然而,當(dāng)GC停頓太長(zhǎng),就會(huì)開始影響應(yīng)用的響應(yīng)時(shí)間。消除或者減少GC停頓時(shí)長(zhǎng),Java將對(duì)更廣泛的應(yīng)用場(chǎng)景是一個(gè)更有吸引力的平臺(tái)。此外,現(xiàn)代系統(tǒng)中可用內(nèi)存不斷增長(zhǎng), 用戶和程序員希望JVM能夠以高效的方式充分利用這些內(nèi)存,并且無(wú)需長(zhǎng)時(shí)間的GC暫停時(shí)間。

ZGC一個(gè)并發(fā),基于region,壓縮型的垃圾收集器,只有root掃描階段會(huì)STW,因此GC停頓時(shí)間不會(huì)隨著堆的增長(zhǎng)和存活對(duì)象的增長(zhǎng)而變長(zhǎng)。

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)階段,所以需要通過(guò)JVM參數(shù)UnlockExperimentalVMOptions 來(lái)解鎖這個(gè)特性。

參考:http://openjdk.java.net/projects/jdk/11/

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容