千呼萬(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)行:
- 啟動(dòng)一個(gè)class文件;
- 啟動(dòng)一個(gè)JAR中的main方法類;
- 啟動(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è)特性。