千呼萬喚，JDK11于2018-09-25正式發布！你是不是和筆者一樣還在使用JDK8呢？甚至有些開發者還在使用JDK7！沒關系，讓我們先一睹JDK11的風采。

JDK11發布計劃

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

說明：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

特性詳解

接下來對每個特性進行詳細解讀。

JEP 318: Epsilon: A No-Op Garbage Collector

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兩個模塊在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/artifact/javax/javaee-api/8.0），所以沒必要把JavaEE包含到JavaSE中。

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

JEP 321: HTTP Client (Standard)

將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表達式的形參時允許使用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

用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/Unicode10.0.0/）。

---

動機

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

JEP 328: Flight Recorder

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

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

---

動機

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

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

多說一句：Flight Recorder的名字來源有點像來自于飛機的黑盒子，一種用來記錄飛機飛行情況的的儀器。而Flight Recorder就是記錄Java程序運行情況的工具。

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

實現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啟動器能以三種方式運行：

啟動一個class文件；

啟動一個JAR中的main方法類；

啟動一個模塊中的main方法類；

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

JEP 331: Low-Overhead 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允許客戶端和服務端通過互聯網以一種防止竊聽，篡改以及消息偽造的方式進行通信）。

---

動機

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

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

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停頓時間比較：

ZGCavg: 1.091ms (+/-0.215ms)95th percentile: 1.380ms99th percentile: 1.512ms99.9th percentile: 1.663ms99.99th percentile: 1.681msmax: 1.681msG1avg: 156.806ms (+/-71.126ms)95th percentile: 316.672ms99th percentile: 428.095ms99.9th percentile: 543.846ms99.99th percentile: 543.846msmax: 543.846ms

用法：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC，因為ZGC還處于實驗階段，所以需要通過JVM參數UnlockExperimentalVMOptions 來解鎖這個特性。

?

總結

以上是生活随笔為你收集整理的重磅：JDK11正式发布！史上最全所有特性完整解读！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。