甲骨文公司表示低暫停G1垃圾回收機制將在取代Parallel GC提高系統(tǒng)執(zhí)行效率。

為龍州等地區(qū)用戶提供了全套網(wǎng)頁設計制作服務，及龍州網(wǎng)站建設行業(yè)解決方案。主營業(yè)務為成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設、龍州網(wǎng)站設計，以傳統(tǒng)方式定制建設網(wǎng)站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

目前甲骨文正計劃將G1服務器垃圾回收機制作為32位與64位Java服務器配置方案中的默認回收選項，但這種處理方式可能帶來一系列后續(xù)問題。

正如于今年早些時候***發(fā)布并于本月剛剛進行了更新的JEP（即JDK增強方案）248所指出，此次回收機制變更的動機在于將暫停時間引入內(nèi)存管理?！耙话銇碇v，限制GC暫停時間要比***限度提升吞吐能力更為重要，”這份建議指出?！岸x擇G1這類低暫停垃圾回收方案應該能夠為大多數(shù)用戶帶來更出色的整體使用體驗——至少相較于主要面向吞吐能力的當前默認選項Parallel GC是如此?！舜巫兏饕谝豁椉僭O，即限制延遲水平通常要優(yōu)先于提升吞吐能力。如果這一假設并不準確，那么此次調(diào)整可能無法帶來理想的效果、甚至需要重新加以審視。”

甲骨文方面的計劃是將G1部署在將于明年推出的Java 9當中。在JDK（即Java開發(fā)工具）8及其后續(xù)更新版本當中，G1已經(jīng)迎來了多項性能改進。而根據(jù)JEP文檔的說法，其應該還會在JDK 9內(nèi)得到進一步提升。

甲骨文公司的一份說明文檔指出，G1的定位是專門面向擁有大容量內(nèi)存及多處理器設備的服務器型垃圾收集方案。不過將其作為默認收集機制可能會暴露出G1當中某些原本不為人知的潛在問題，JEP 248指出。“如果其中出現(xiàn)了某些在JDK 9生命周期之內(nèi)無法解決的問題，那么我們將重新將Parallel GC作為JDK 9通用版本的默認垃圾回收方案?！盙1還提供多種不同資源使用方式?！爱斮Y源使用率需要被控制在***水平時，用戶應該優(yōu)先選擇其它垃圾回收機制來取代G1，而在變更之后、后備回收機制必須得到明確指定。”

Parallel GC這套并行垃圾回收方案多年來一直在Java當中充當默認選項，而需要盡可能壓縮垃圾回收暫停時間的應用程序則主要采用Concurrent Mark Sweep——后者同樣屬于備選方案，Java虛擬機技術供應商Azul Systems公司Scott Sellers指出。G1是一套全新實現(xiàn)方案，其代碼更加簡潔而且在維護方面上對開發(fā)人員更加友好，因此“一部分用戶可能更傾向于使用G1作為演進后的處理手段，”Sellers解釋稱。

不過G1也有著自己的弊端，包括較并行垃圾收集機制而言數(shù)據(jù)吞吐速度較慢且性能較差，他表示。“G1的另一大短板在于，如果某款應用程序需要擁有非常嚴格的響應時間特性，那么經(jīng)過精確調(diào)整的CMS垃圾回收機制在幾乎各種情況下都能提供優(yōu)于G1的響應時間指標。”

新聞標題：Java9許愿清單：請賜予我們更理想的垃圾回收機制
分享地址：http://uogjgqi.cn/article/cdsheii.html