淺析 Sun JVM 垃圾回收機制與 System.gc() 調用策略

本文針對 Sun JVM (HotSpot) 的垃圾回收線程優先級、自動回收與手動觸發 System.gc() 的差異、以及生產環境 JVM 選型建議進行淺析，旨在幫助開發者理解 GC 行為，避免盲目調用導致性能抖動。

一、自動回收 vs 手動 System.gc()

• 自動回收線程優先級最低：屬於守護線程，當系統繁忙、CPU 壓力大時，GC 線程極難獲得調度機會，導致內存無法及時釋放，甚至觸發 Full GC 停頓。
• 手動 System.gc() 優先級高（用戶線程級別）：調用即強制觸發 GC，回收效果顯著（特別在 J2ME 等資源受限環境驗證過），但會導致 Stop-The-World 全線程停頓，影響系統響應。

二、建議策略：適時、雙次調用

在「適當時機」（如批次任務結束、緩存清理後、進入空閒期）調用 兩次 System.gc() 可較大概率觸發 Full GC 並回收浮動垃圾。「兩次」為經驗值，具體視對象存活分布而定，建議通過 -XX:+PrintGCDetails 觀察實際回收效果後調整。

三、JVM 選型建議：開發用 Sun，生產用 JRockit

• Sun HotSpot (JDK/JRE)：啟動快、調試友好，適合開發、測試環境。
• BEA JRockit (現 Oracle JRockit)：並行/分代收集器，GC 線程與應用線程同優先級、真正並行不停頓；更細粒度的堆管理；大幅提升吞吐與響應。生產環境強烈推薦，官網可免費下載。

四、總結

理解 GC 線程調度特性，避免在高併發關鍵路徑盲目調用 System.gc()；利用 -verbose:gc 或 -XX:+PrintGCDetails 監控 GC 頻率與停頓；生產環境考慮遷移至並行收集器（JRockit 或 JDK 6+ Parallel GC / JDK 7+ G1）以獲得確定性性能表現。