導讀：新版本主要有三大變化：同步了 OpenJDK 上游社區(qū) jdk8u222-ga 的最新更新；帶來了正式的 feature：G1ElasticHeap；發(fā)布了用戶期待的 Windows 實驗版本 Experimental Windows version。
距離 Dragonwell JDK 第一個正式版本 8.0.0-GA 發(fā)布已經(jīng)過去 3 個月了，項目在 Github 上的 stars 繼續(xù)攀升達到了 1900。今天我們帶來了最新版本 8.1.1-GA 的發(fā)布，包含了全新的特性和更新。詳情見下文。
龍井 8.1.1-GA 的新變化
新版本里我們同步了 OpenJDK 上游社區(qū) jdk8u222-ga 的最新更新，帶來了上游穩(wěn)定版本的最新安全更新和補丁。
在 8.0.0-GA 發(fā)布的時候，我們介紹了 Dragonwell 第三個新特性 ElasticHeap 的一些情況，很多用戶已經(jīng)躍躍欲試了，這次發(fā)布我們帶來了正式的 feature：G1ElasticHeap。能夠在不影響 Java 業(yè)務運行的前提下，動態(tài)節(jié)約 Java 進程物理內(nèi)存。
另外，我們還發(fā)布了用戶期待的 Windows 實驗版本 Experimental Windows version，使用 Windows 開發(fā)的小伙伴們可以更加方便的使用 Dragonwell JDK 進行相應的開發(fā)工作。
G1ElasticHeap
從 feature 的名字上我們可以看到 ElasticHeap 是基于 G1 GC 開發(fā)的，所以想要使用這個功能的小伙伴，需要開啟 G1 GC(-XX:+UseG1GC)。在 8.0.0-GA 正式版介紹時，我們介紹了部分技術(shù)背景，由于 Java 自動管理內(nèi)存的特性，整個 Java Heap 的地址空間和物理內(nèi)存將被 Java 進程占用，即使使用率不高，回收后也并不會歸還給操作系統(tǒng)，導致 Java 進程會有較高的常駐內(nèi)存。
OpenJDK8 的幾個常規(guī) GC 算法僅能支持在 Full GC 時，按照一定規(guī)則有限縮減 Java 堆，然而 Java 開發(fā)的小伙伴們非常清楚，頻繁的 Full GC 的 STW（stop-the-world）對 Java 應用意味著什么，長暫停會導致很多不可預期的應用異常和無法響應。
ElasticHeap 可以根據(jù)整體 GC 的壓力，敏捷地將 Java 堆的物理內(nèi)存歸還給操作系統(tǒng)，沒有額外的 STW 對 Java 應用帶來的超時異常風險，核心設(shè)計有 2 個特別之處：
- 分別處理 Java Heap 中新區(qū)和老區(qū)的部分。特別是不少應用為了維持可能高壓力下的 GC 吞吐，會保持比較大的 young generation，例如 G1 默認的新區(qū)最大值為整堆的 60%。當 young GC 頻率不高時，其實 Java 堆面臨很大程度的浪費，但卻沒有辦法快速節(jié)約這部分內(nèi)存。假設(shè)當新區(qū)為整堆 60%，young GC 頻率為 90 秒一次。當使用整堆 10% 作為 young generation 時，GC 頻率變?yōu)?15 秒一次，同樣可以滿足 Java 正常運行，這樣就可以節(jié)約 50% 的 Java 堆內(nèi)存。而當壓力變大，GC 頻率變高時，會自動檢測到變化并且重新 map 內(nèi)存擴展新區(qū)的大小。
- 使用了并發(fā)線程，并發(fā)且并行（concurrent and parallel）處理內(nèi)存歸還和重新 map 的工作。因為和 Linux kernel 交互，map/unmap 內(nèi)存實際上是比較耗時的操作，特別是重新 map 內(nèi)存后還會有 page fault 的開銷，對于一次操作上 G 的內(nèi)存，很容易消耗上百毫秒，甚至是秒級。因此，如果傳統(tǒng)地在 GC STW中 操作內(nèi)存 map/unmap，Java 應用將可能發(fā)生較大的毛刺，這是很多在線服務型應用不可接受的。通過并發(fā)線程并行處理 unmap 以及重新 map 后帶來的 page fault 的開銷，Java 應用線程將不受任何影響。在常規(guī) GC STW 過程中，Java 堆的容量將會及時同步完成。
在 OpenJDK 新的 12 版本中，也引入了周期性觸發(fā) G1 concurrent mark 來觸發(fā)內(nèi)存的節(jié)約機制，但是并沒有解決在 STW中map/unmap 的開銷問題，也不能快速在 young GC 周期中來發(fā)現(xiàn)和處理 young generation 的內(nèi)存浪費。目前除了在 Dragonwell 8.1.1 中發(fā)布，我們同時把 G1ElasticHeap 的 patch 提交給 OpenJDK 社區(qū) review 和討論，希望將這些創(chuàng)造性的變化加入到最新的 OpenJDK G1 GC 中。
云棲大會上孤盡的演講，清晰地描述了 ElasticHeap 的使用場景。在雙 11 流量劇增的情況下，核心應用 tradeplatform3 迅速的回漲 Java heap 和內(nèi)存，以保持高流量壓力下的穩(wěn)定。高峰過后，內(nèi)存逐漸縮減。從集群維度來說，在線 Java 應用占據(jù)大量內(nèi)存，即使在線流量低，cpu 利用率很低，由于內(nèi)存的占據(jù)，集群機器的 cpu 資源依然無法復用。而 ElasticHeap 可以有效降低低壓力的在線 Java 應用的內(nèi)存占用，把內(nèi)存資源出讓一部分運行離線任務，從而突破在線應用集群的資源利用率的內(nèi)存瓶頸。在本例中，節(jié)約了 22.8% 的 Java 進程的物理內(nèi)存。
想要立刻使用最新特性的小伙伴們，可以通過下面的地址下載最新版本的 Dragonwell JDK 的二進制包。
https://github.com/alibaba/dragonwell8/releases
這里提供了用戶指南和發(fā)布說明。用戶指南的末尾還有支持的釘釘群和郵件。
https://github.com/alibaba/dragonwell8/wiki
如果有小伙伴覺得這個特性符合自身的場景需求好用的話，不妨也向 OpenJDK 社區(qū)郵件列表支持我們，讓 OpenJDK 聽到更多中國 Java 使用者和開發(fā)者的聲音。
總結(jié)
以上所述是小編給大家介紹的阿里巴巴開源 Dragonwell JDK 最新版本 8.1.1-GA 發(fā)布,希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！
如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！
