您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 相關知識

深度解析 Java 垃圾回收機制與記憶體洩漏成因

編輯：Java 相關知識

前言

Java 擁有自動垃圾回收（GC）機制，但這並不意味著記憶體洩漏不會發生。本文將深入剖析 JVM 中對象的三種可達性狀態、GC 判定邏輯、finalize 方法的角色，並通過一個經典的「棧實現」案例演示如何因疏忽導致記憶體洩漏，最後給出修正方案與最佳實踐。

一、JVM 堆中對象的三種狀態

對於 GC 執行緒而言，堆上對象僅有三種狀態：

可觸及：程式中仍有變量引用該對象。
可復活：無引用，但 finalize() 尚未執行；在 finalize() 中若重新建立引用，可轉回可觸及。
不可觸及：finalize() 已執行（或無此方法）且無引用，只有此時 GC 才會回收記憶體。

二、GC 的不可預測性

不同 JVM 實現採用不同演算法（Serial、Parallel、CMS、G1、ZGC 等），開發者無法精確預知 GC 何時掃描、何時調用 finalize()、何時釋放記憶體。
System.gc() / Runtime.gc() 僅是建議，不保證立即執行。

三、記憶體洩漏的本質

因程式設計缺陷，導致本應廢棄的對象持續被引用，GC 無法回收，造成記憶體佔用持續增長，最終可能拋出 OutOfMemoryError。

四、經典案例：自定義棧導致的洩漏

有問題的實現

public class MyStack {
    private Object[] elements;
    private int size = 0;

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

    public Object pop() {
        if (size == 0) throw new EmptyStackException();
        return elements[--size]; // 錯誤：未清除陣列中殘留的引用
    }
    // ... 省略擴容邏輯
}

後果：彈出後，elements[size] 仍持有對象引用，GC 認為對象「可觸及」，記憶體永不釋放。

修正版

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

五、常見洩漏場景速查

場景	原因	對策
集合類未清理	List/Map 持有過期對象	及時 `remove()`、`clear()` 或置 null
靜態集合	生命週期等同類，易累積	避免靜態持有大量數據，或用弱引用
監聽器/回調未移除	註冊後未反註冊	在 destroy/onStop 中移除
ThreadLocal 洩漏	線程池複用導致值不釋放	用完即 `remove()`
內部類持有外部引用	非靜態內部類隱含外部引用	改靜態內部類或弱引用