Java 垃圾收集核心算法與性能優化實戰指南

GC 核心思想：識別存活與回收垃圾

Java 垃圾收集機制旨在追蹤正在使用的對象，發現並回收不再被引用的對象，有效防範動態內存分配中的兩大風險：內存耗盡與非法引用。GC 演算法的核心在於對堆空間對象進行識別——被引用即為「存活對象」，反之則為「垃圾對象」，可回收其空間供再分配。GC 算法選擇與參數調優直接決定系統性能，開發者需深入理解。

主 GC 觸發條件與不確定性

JVM 主 GC（Major GC）影響顯著，主要由兩條件觸發：

1. 應用程序空閒時：GC 運行於最低優先級線程，僅在無應用線程執行時被調度。
2. Java 堆內存不足時：創建新對象時空間不夠，JVM 強制觸發 GC。若連續三次 GC 仍無法滿足分配，拋出 OutOfMemoryError 導致應用停止。

因系統環境動態變化，主 GC 運行時間不可預測，但長期運行應用必會反覆觸發。

七大減少 GC 開銷的編碼原則

1. 避免顯式調用 System.gc()：僅為建議，但常觸發主 GC，增加間歇性停頓。
2. 減少臨時對象創建：方法調用結束即成垃圾，少用臨時變量可延緩內存壓力。
3. 不用對象顯式置 null：助 GC 快速判定垃圾，提升收集效率。
4. 字符串拼接用 StringBuffer/StringBuilder：避免 String 不變性導致大量中間對象（如 Str1+Str2+Str3 產生多個過渡對象）。
5. 優先使用基本類型（int/long）而非包裝類：內存佔用遠小於對象。
6. 慎用靜態對象變量：屬全局變量，GC 不回收，長期佔用內存。
7. 分散對象創建/刪除時間：避免短時大量分配或釋放導致頻繁主 GC 或內存碎片整理。

gc() 與 finalize() 深度解析

System.gc()：請求而非命令

調用 System.gc() 僅請求 JVM 執行 GC，JVM 會對演算法加權，使回收更易發生、更早發生或回收更多，但不保證立即執行。

finalize()：對象消亡前的最後機會

JVM 回收對象前會調用 protected void finalize() throws Throwable，可用於釋放非內存資源（如文件句柄、數據庫連接）。但不可依賴它釋放關鍵資源，因調用時間不確定。

class Garbage {
    int index; static int count;
    Garbage() { count++; System.out.println("object " + count + " construct"); setID(count); }
    void setID(int id) { index = id; }
    protected void finalize() { System.out.println("object " + index + " is reclaimed"); }
    public static void main(String[] args) {
        new Garbage(); new Garbage(); new Garbage(); new Garbage();
        System.gc(); // 請求 GC
    }
}

Java 內存洩漏：本質與典型場景

洩漏本質：無意識的對象保持

Java 所謂「內存洩漏」實為開發者非故意保留對象引用（如集合中未移除已不用元素），導致 GC 無法回收本可釋放的空間。

經典案例：棧實現缺陷

public class ObjStack {
    private Object[] stack; private int index;
    ObjStack(int size) { stack = new Object[size]; index = 0; }
    public void push(Object obj) { stack[index++] = obj; }
    public Object pop() { return stack[--index]; } // 錯誤：未清除引用
    // 正確：Object temp = stack[--index]; stack[index] = null; return temp;
}

pop 僅遞減索引，數組仍持有對象引用，導致 32 個出棧對象無法被 GC 回收。

常見洩漏模式與對策

• 全局集合（JNDI、Session 表）：需定期清理任務或引用計數機制移除失效條目。
• 無上限緩存：採用 LRU 淘汰策略或 SoftReference，確保內存佔用可控。
• ClassLoader 洩漏：靜態字段、線程本地變量持有類引用會阻止 ClassLoader 卸載，需在應用卸載時清理。

診斷與定位洩漏

首發信號通常是生產環境 OutOfMemoryError。持續監控 GC 活動，若內存使用隨時間單調增長，極大概率存在洩漏。建議使用低開銷工具（如 JConsole、VisualVM、Eclipse MAT）在線分析堆轉儲，定位 GC Roots 引用鏈，找出洩漏根因，且不重啟系統、不修改代碼即可接入。