[Java] 關於 Garbage Collection 的二三事(一)
垃圾優先行垃圾收集(G1 GC)(–XX:+UseG1GC)
最後,讓我們一起學習垃圾優先型垃圾收集。
若你想學會 G1 GC,你必須先將先前所學,所有有關新舊世代的東西通通拋諸腦後。如同你在上圖中看到的,每一個物件都被分別放在格子中,當一個格子不夠大時,會再分配一個格子給它。我們先前所熟悉的,新世代中三個分區的資料移動、舊世代區,在 G1 GC 中都不存在。這個方法是用來取代 CMS GC 的,因為後者在長期來看會造成許多的問題和壓縮的必須性。
G1 GC 的最大優勢是效能,它比任何我們到目前為止討論到的垃圾收集方式都要來的快。但要記住,在 JDK 6 中這個方式仍屬於前期預覽(early access)的狀態,僅提供測試用途,在 JDK 7 時正式加入,但建議你先稍待一年,等其他廠商確認相容性後再行採用;另外,筆者也聽過部分在 JDK 6 環境中,因採用了 G1 GC 之後造成 JVM 崩潰(crash)的案例。
(譯註:JDK 7 已經面世好一段時間了,甚至連 JDK 8 都已經進入到 u54,G1 GC 技術理應當已經成熟,這段建議就當作JDK 版本轉換時的提醒吧!)
在下一章節中,我們將會討論到如何調教垃圾收集,但在那之前,我想先問你一個問題:若是應用程式所建立的所有物件大小都是已知的,所有用在網頁應用程式伺服器的 GC 選項都是相同的,但大小和生命週期卻又因服務而有所不同,且伺服器的機種又有所差異,該怎麼辦?換句話說,不會因為某個服務使用 “A” 選項跑得最快,套用在其他的服務上就會得到最好的結果,最佳化的設定是必須要去不斷測試和找尋的,因此需要不斷的監控和調教。這並非我個人的一己之見,而是在 JavaOne 2010 中,開發出 Oracle JVM 的工程師們的討論結果。
因為篇幅的限制,在本篇文章中僅能帶大家匆匆一瞥,請期待我們的下一篇文章,我將會討論到 如何監控 和 調教 Java 的垃圾收集
哇~ 終於翻完了,第一次挑戰長文翻譯,翻得不好的地方也請大家見諒,另外,本文也將同步刊載在 AlexLeo 的網路小窩,和 MyCraft 粉絲團,請大家多多抔捧場喔!
後記:下一篇嘛…. 這… 就要再看看大家的反應了(笑)