阿里巴巴開源 Dragonwell JDK 最新版本 8.1.1-GA 發佈

導讀：新版本主要有三大變化：同步了 OpenJDK 上游社區 jdk8u222-ga 的最新更新；帶來了正式的 feature：G1ElasticHeap；發佈了用戶期待的 Windows 實驗版本 Experimental Windows version。

距離 Dragonwell JDK 第一個正式版本 8.0.0-GA 發佈已通過去 3 個月了，項目在 Github 上的 stars 繼續攀升達到了 1900。今天咱們帶來了最新版本 8.1.1-GA 的發佈，包含了全新的特性和更新。詳情見下文。

龍井 8.1.1-GA 的新變化

新版本里咱們同步了 OpenJDK 上游社區 jdk8u222-ga 的最新更新，帶來了上游穩定版本的最新安全更新和補丁。

在 8.0.0-GA 發佈的時候，咱們介紹了 Dragonwell 第三個新特性 ElasticHeap 的一些狀況，不少用戶已經躍躍欲試了，此次發佈咱們帶來了正式的 feature：G1ElasticHeap。可以在不影響 Java 業務運行的前提下，動態節約 Java 進程物理內存。

另外，咱們還發布了用戶期待的 Windows 實驗版本 Experimental Windows version，使用 Windows 開發的小夥伴們能夠更加方便的使用 Dragonwell JDK 進行相應的開發工做。

G1ElasticHeap

從 feature 的名字上咱們能夠看到 ElasticHeap 是基於 G1 GC 開發的，因此想要使用這個功能的小夥伴，須要開啓 G1 GC(-XX:+UseG1GC)。在 8.0.0-GA 正式版介紹時，咱們介紹了部分技術背景，因爲 Java 自動管理內存的特性，整個 Java Heap 的地址空間和物理內存將被 Java 進程佔用，即便使用率不高，回收後也並不會歸還給操做系統，致使 Java 進程會有較高的常駐內存。

OpenJDK8 的幾個常規 GC 算法僅能支持在 Full GC 時，按照必定規則有限縮減 Java 堆，然而 Java 開發的小夥伴們很是清楚，頻繁的 Full GC 的 STW（stop-the-world）對 Java 應用意味着什麼，長暫停會致使不少不可預期的應用異常和沒法響應。

ElasticHeap 能夠根據總體 GC 的壓力，敏捷地將 Java 堆的物理內存歸還給操做系統，沒有額外的 STW 對 Java 應用帶來的超時異常風險，核心設計有 2 個特別之處：

1. 分別處理 Java Heap 中新區和老區的部分。特別是很多應用爲了維持可能高壓力下的 GC 吞吐，會保持比較大的 young generation，例如 G1 默認的新區最大值爲整堆的 60%。當 young GC 頻率不高時，其實 Java 堆面臨很大程度的浪費，但卻沒有辦法快速節約這部份內存。假設當新區爲整堆 60%，young GC 頻率爲 90 秒一次。當使用整堆 10% 做爲 young generation 時，GC 頻率變爲 15 秒一次，一樣能夠知足 Java 正常運行，這樣就能夠節約 50% 的 Java 堆內存。而當壓力變大，GC 頻率變高時，會自動檢測到變化而且從新 map 內存擴展新區的大小。
2. 使用了併發線程，併發且並行（concurrent and parallel）處理內存歸還和從新 map 的工做。由於和 Linux kernel 交互，map/unmap 內存其實是比較耗時的操做，特別是從新 map 內存後還會有 page fault 的開銷，對於一次操做上 G 的內存，很容易消耗上百毫秒，甚至是秒級。所以，若是傳統地在 GC STW中 操做內存 map/unmap，Java 應用將可能發生較大的毛刺，這是不少在線服務型應用不可接受的。經過併發線程並行處理 unmap 以及從新 map 後帶來的 page fault 的開銷，Java 應用線程將不受任何影響。在常規 GC STW 過程當中，Java 堆的容量將會及時同步完成。

在 OpenJDK 新的 12 版本中，也引入了週期性觸發 G1 concurrent mark 來觸發內存的節約機制，可是並無解決在 STW中map/unmap 的開銷問題，也不能快速在 young GC 週期中來發現和處理 young generation 的內存浪費。目前除了在 Dragonwell 8.1.1 中發佈，咱們同時把 G1ElasticHeap 的 patch 提交給 OpenJDK 社區 review 和討論，但願將這些創造性的變化加入到最新的 OpenJDK G1 GC 中。

雲棲大會上孤盡的演講，清晰地描述了 ElasticHeap 的使用場景。在雙 11 流量劇增的狀況下，核心應用 tradeplatform3 迅速的回漲 Java heap 和內存，以保持高流量壓力下的穩定。高峯事後，內存逐漸縮減。從集羣維度來講，在線 Java 應用佔據大量內存，即便在線流量低，cpu 利用率很低，因爲內存的佔據，集羣機器的 cpu 資源依然沒法複用。而 ElasticHeap 能夠有效下降低壓力的在線 Java 應用的內存佔用，把內存資源出讓一部分運行離線任務，從而突破在線應用集羣的資源利用率的內存瓶頸。在本例中，節約了 22.8% 的 Java 進程的物理內存。

想要馬上使用最新特性的小夥伴們，能夠經過下面的地址下載最新版本的 Dragonwell JDK 的二進制包。
https://github.com/alibaba/dragonwell8/releases
這裏提供了用戶指南和發佈說明。用戶指南的末尾還有支持的釘釘羣和郵件。
https://github.com/alibaba/dragonwell8/wiki

若是有小夥伴以爲這個特性符合自身的場景需求好用的話，不妨也向 OpenJDK 社區郵件列表支持咱們，讓 OpenJDK 聽到更多中國 Java 使用者和開發者的聲音。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」

搜索「阿里巴巴雲原生公衆號」獲取更多K8s容器技術內容