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