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

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

[[137646]]

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

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

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

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

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

原文標題：Cleaner garbage collector wanted for Java 9