JVM 垃圾回收核心機制深度解析：從引用計數到分代收集

垃圾回收 (GC) 是 Java 自動記憶體管理的基石。本文系統講解 GC 的判定演算法、主流收集器類型、JVM 實作演進，並給出調優關鍵點，幫助開發者理解 JVM 記憶體行為、排查 OOM 與長停頓問題。

物件存活判定：兩大經典演算法

引用計數法

每個物件維護一個計數器，引用+1，失效-1，歸零即可回收。優點：即時性強、停頓極短。致命缺陷：無法解決循環引用（A→B、B→A 計數永不歸零），早期 JVM 已棄用。

可達性分析（根搜索/追蹤收集）

從 GC Roots（棧帧局部變數、靜態屬性、常數、JNI 引用等）出發，走對象圖標記可達物件。不可達者判定為垃圾。現代所有主流 JVM（HotSpot、OpenJ9、Zing 等）均採用此法。

三大經典收集演算法

HotSpot 分代收集策略

基於「弱分代假說」：多數物件朝生夕死、少數長期存活。堆劃分為：

• 新生代：Eden + 2 個 Survivor（S0/S1），採用複製演算法，Minor GC 頻繁且快。
• 老年代：長壽命物件，採用標記-整理，Major/Full GC 耗時長。

主流垃圾收集器對比

開發者必知的 GC 細節

1. finalize() 僅執行一次，異常不阻礙回收，不建議依賴它釋放資源（改用 try-with-resources / Cleaner）。
2. 物件在 finalize() 中「復活」僅生效一次，下次 GC 直接回收。
3. System.gc() 僅是建議，JVM 可忽略；生產環境避免顯式調用。
4. 記憶體洩漏本質：長生命周期物件持有短生命周期物件引用（如靜態集合、未關閉的流、監聽器未移除）。

圖示：根節點可達性分析標記過程