java 11 新特性

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 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 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 331: Low-Overhead Heap Profiling

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

• 足夠低的開銷，能夠默認且一直開啓；

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

• 能採樣全部分配；

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

動機

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

 

 

 

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

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

 

 

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