JVM 記憶體管理雜談：關於 obj=null 的誤區與記憶體洩漏真相

前言

許多 Java 教材建議「用完物件顯式設為 null」，實則是 C/C++ 手動釋放記憶體思維的殘留。`obj=null` 僅切斷引用變數與實例的關聯，實例記憶體並未立即釋放，需等待 GC。

為何會有這個建議？

針對不熟悉 GC 與變數作用域的開發者，機械式設 null 可減少因作用域過大導致的誤佔用記憶體，甚至避免某些隱蔽洩漏。但這治標不治本，且降低代碼可讀性。

真實洩漏案例：自定義 Stack

public class Stack {
    private Object[] datas;
    private int size;
    public Object pop() {
        if (size == 0) throw new IndexOutOfBoundsException();
        return datas[--size]; // 邏輯洩漏：陣列仍持有彈出物件引用
    }
}

若曾 push 100 萬物件，pop 後僅剩 1 個，陣列仍持有 100 萬引用，GC 無法回收。正確做法：

public Object pop() {
    Object data = datas[--size];
    datas[size] = null; // 手動斷開引用
    return data;
}

這類洩漏極隱蔽，隨 Stack 回收才釋放，易被忽略。

根本解決之道

機械式 `obj=null` 非銀彈。真正有效的是：

1. 掌握 GC 策略與原理
2. 嚴格控制變數作用域（盡量局部化、儘早失效）
3. 理解引用類型（強/軟/弱/虛）與集合框架特性

培訓班出身的開發者尤應補齊 JVM 內功，勿只專注框架業務。

結語

記憶體管理是 Java 內功心法，`obj=null` 只是招式。修煉內功，方能游刃有餘。

作者：zuoxiaolong（左潇龍）
出處：博客園左潇龍的技術博客