JDK11新特性學習（二）

// JDK9 --> JDK11

非同步HTTP客戶端

JDK9開始引入，JDK11中正式可用。

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder(URI.create("www.baidu.com")).build();
BodyHandler<String> ResponseBodyHandler = BodyHandlers.ofString();
// 同步
HttpResponse response = client.send(request, responseBodyHandler);
System.out.println(response.body());
// 非同步
CompletableFuture<HttpResponse<String>> sendAsync = client.sendAsync(request, responseBodyHandler);
HttpResponse<String> response = sendAsync.get();
System.out.println(response.body());

JDK11移除內容

主要移除一些使用很少的功能，比如：
移除了Thread.destory() Thread.stop(Throwable)
移除了javafx openjdk
移除了java mission control
移除了xml有關的所有模組，僅留下java.xml.crypto jdk.xml.dom java.xml
…
PS: java都移除了javafx，學校老師還在上這門課 o(>﹏<)o

Unicode 10新增字元

新增了56個emoji表情符號、8518個字元，字元總數達到了136690，從而原來的兩個位元組已經無法處理。
lang包下新增了處理字元的類CharacterDateXX，以及String類中原有的與CodePoints有關的方法，用來處理超過大小的字元。

Epsilon GC

JDK中對這個垃圾收集器的描述是：處理記憶體分配但不實現任何實際記憶體回收機制的gc，一旦堆記憶體用完JVM就退出
指出如果呼叫System.gc()也是沒有效果的

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC
# 效果等價於
-XX:+DisableExplicitGC

主要用途：

1. 效能測試，過濾掉由於GC引起的效能假象
2. 記憶體壓力測試
3. 執行所需時間非常短的任務，GC是在浪費時間空間

ZGC

特點：伸縮低延遲（Scalable Low-Latency），即能處理幾百兆小堆，也能處理幾T大堆。只有root掃描階段會STW，GC停頓時間不會隨著堆增長和存活物件增長而增長。
設計目標：支援TB級別的記憶體管理，暫停時間<10ms，對程式吞吐量影響<15%
本質：ZGC是一個併發的，基於區（region）的壓縮型垃圾收集器，它用42位描述記憶體地址編號，從而支援了TB級別的記憶體管理，用剩下的22位可以擴充套件實現機制，例如多層堆（熱物件與冷物件分層），壓縮堆等

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC 

PS: JVM這塊可以看我之前的部落格進行理解！

G1增強

JDK11實現G1的並行full GC，快速的CardTable掃描，更方便的GC配置和調優等

完全支援linux容器

在JDK9之前JVM無法識別容器使用標誌設定的記憶體限制和CPU限制，導致應用效能下降。（JDK9：什麼Σ(⊙▽⊙"!，我竟然在docker中執行）
JVM現在可以識別容器控制組（cgroups）設定的約束