甲骨文公司表示低暫停G1垃圾回收機制將在取代Parallel GC提高系統執行效率。
目前甲骨文正計劃將G1服務器垃圾回收機制作為32位與64位Java服務器配置方案中的默認回收選項，但這種處理方式可能帶來一系列後續問題。
正如於今年早些時候首次發布並於本月剛剛進行了更新的JEP（即JDK增強方案）248所指出，此次回收機制變更的動機在於將暫停時間引入內存管理。“一般來講，限制GC暫停時間要比最大限度提升吞吐能力更為重要，”這份建議指出。“而選擇G1這類低暫停垃圾回收方案應該能夠為大多數用戶帶來更出色的整體使用體驗——至少相較於主要面向吞吐能力的當前默認選項Parallel GC是如此。……此次變更主要基於一項假設，即限制延遲水平通常要優先於提升吞吐能力。如果這一假設並不准確，那麼此次調整可能無法帶來理想的效果、甚至需要重新加以審視。”
甲骨文方面的計劃是將G1部署在將於明年推出的Java 9當中。在JDK（即Java開發工具）8及其後續更新版本當中，G1已經迎來了多項性能改進。而根據JEP文檔的說法，其應該還會在JDK 9內得到進一步提升。
甲骨文公司的一份說明文檔指出，G1的定位是專門面向擁有大容量內存及多處理器設備的服務器型垃圾收集方案。不過將其作為默認收集機制可能會暴露出G1當中某些原本不為人知的潛在問題，JEP 248指出。“如果其中出現了某些在JDK 9生命周期之內無法解決的問題，那麼我們將重新將Parallel GC作為JDK 9通用版本的默認垃圾回收方案。”G1還提供多種不同資源使用方式。“當資源使用率需要被控制在最低水平時，用戶應該優先選擇其它垃圾回收機制來取代G1，而在變更之後、後備回收機制必須得到明確指定。”
Parallel GC這套並行垃圾回收方案多年來一直在Java當中充當默認選項，而需要盡可能壓縮垃圾回收暫停時間的應用程序則主要采用Concurrent Mark Sweep——後者同樣屬於備選方案，Java虛擬機技術供應商Azul Systems公司Scott Sellers指出。G1是一套全新實現方案，其代碼更加簡潔而且在維護方面上對開發人員更加友好，因此“一部分用戶可能更傾向於使用G1作為演進後的處理手段，”Sellers解釋稱。
不過G1也有著自己的弊端，包括較並行垃圾收集機制而言數據吞吐速度較慢且性能較差，他表示。“G1的另一大短板在於，如果某款應用程序需要擁有非常嚴格的響應時間特性，那麼經過精確調整的CMS垃圾回收機制在幾乎各種情況下都能提供優於G1的響應時間指標。”
原文標題：Cleaner garbage collector wanted for Java 9
