Java 記憶體洩漏深度剖析：成因、誤區與自癒機制

許多開發者認為「Java 有 GC 就不會記憶體洩漏」，這是危險的誤解。本文從 JVM 回收機制出發，深度解析 Java 記憶體洩漏的真實定義、經典案例、自癒特性、常見誤判場景，建立正確的記憶體管理認知體系。

核心定義對比

Java 記憶體洩漏必要條件

同時滿足：

1. 物件 無用 (業務邏輯不再需要)
2. 物件 可達 (GC Roots 直接或間接引用)

只要引用鏈存在，GC 就視為「存活」，哪怕業務上已廢棄。

經典案例：Stack 類別洩漏

public class Stack {
    private Object[] elements = new Object[10];
    private int size = 0;

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0) throw new EmptyStackException();
        return elements[--size]; // ❌ 元素仍在陣列中被引用！
    }

    private void ensureCapacity() {
        if (elements.length == size) {
            elements = Arrays.copyOf(elements, 2 * size + 1);
        }
    }
}

洩漏過程演示

1. push 10 個物件 → elements[0..9] 持有引用
2. pop 10 次 → size=0，但 elements[0..9] 仍持有舊物件引用
3. 這 10 個物件 業務無用但 GC 可達 → 記憶體洩漏

修正版

public Object pop() {
    if (size == 0) throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // ✅ 手動切斷引用
    return result;
}

洩漏場景分類與自癒特性

1. 靜態集合持有 (長期洩漏)

public class Bad {
    public static Stack s = new Stack();
    static {
        s.push(new Object());
        s.pop(); // 1 個物件洩漏
        s.push(new Object()); // 新物件進入，舊物件位置被覆蓋 → 自癒！
    }
}

特性：靜態變數生命週期 = JVM 生命週期，但集合容量有上限，最多洩漏 capacity 個物件，屬「可控洩漏」。

2. 方法區域性集合 (短期洩漏 → 自癒)

public void notTooBad() {
    Stack s = new Stack();
    s.push(new Object());
    s.pop(); // 洩漏發生
    // 方法結束，s 變數出作用域 → Stack 物件不可達 → 整個陣列可回收 → 徹底自癒
}

結論：區域性洩漏隨方法結束自動癒合，99.9999% 場景無實質危害，但屬程式碼品質缺陷。

3. 快取無清理策略 (隱性洩漏)

Map cache = new HashMap<>(); // 無大小限制、無過期淘汰
cache.put(key, largeObject); // 持續增長 → OOM

對策：使用 LinkedHashMap 實作 LRU、WeakHashMap、Guava Cache、Caffeine、Redis。

4. 監聽器/回調未移除 (經典洩漏)

button.addActionListener(e -> doSomething());
// 畫面關閉時未 removeActionListener → button 持有 listener → listener 持有外部類引用 → 記憶體洩漏

5. ThreadLocal 濫用 (執行緒池洩漏)

ThreadLocal tl = new ThreadLocal<>();
tl.set(connection);
// 執行緒池重用執行緒，ThreadLocal 不清理 → Connection 永不釋放

鐵律：finally { tl.remove(); }

常見誤判場景 (非洩漏)

1. 多餘賦 null

Object obj = new Object();
obj = null; // ❌ 無意義，離開作用域自動不可達

2. 參數重新賦值

void func(Object o) {
    o = new Object(); // 修改區域參考，不影響呼叫端原物件
} // 方法結束，新物件自動可回收

3. 相互引用 (孤島效應)

class A { B b = new B(this); }
class B { A a; B(A a) { this.a = a; } }

事實：現代 GC (標記-清除/壓縮) 完美處理循環引用，**不會** 造成洩漏。可能略微增加 GC 標記階段耗時，可忽略。

診斷工具鏈

1. JVisualVM / JConsole：堆疊趨勢、GC 頻率、類別統計
2. MAT (Memory Analyzer Tool)：支配者樹、洩漏嫌疑報告、保留集分析
3. Arthas：線上 heapdump、oom 診斷
4. JCmd：jcmd GC.heap_dump
5. GC 日誌分析：-Xlog:gc*:file=gc.log + GCViewer/GCEasy

預防最佳實踐

1. 集合類別 明確生命週期：靜態→弱引用/定期清理；區域性→方法結束自癒
2. 覆寫清理方法：自定義集合/快取必須提供 clear()/evict()
3. ThreadLocal 必配 finally remove()
4. 監聽器/回調對稱註冊銷毀
5. 大物件流式處理：避免一次性載入巨大集合/檔案
6. 定期 Heap Dump 基線對比：CI/CD 管線整合記憶體洩漏檢測

總結

Java 記憶體洩漏 確實存在，但本質不同於 C/C++：

• C/C++：遺漏釋放 → 永久洩漏、必然崩潰
• Java：無意保留引用 → 條件性洩漏、具備自癒能力 (作用域結束、容量上限覆蓋)

核心心法：「誰持有，誰負責釋放」。靜態集合、快取、ThreadLocal、監聽器是四大高危區。建立 try-finally/try-with-resources 肌肉記憶，配合 MAT 定期體檢，Java 記憶體管理完全可控。