要判斷 Java 程式是否存在內存洩漏，首先必須透徹理解 Java 的內存管理機制。Java 的內存管理本質上是對象的分配與釋放問題。在 Java 中，程式設計師通過 new 關鍵字為每個對象申請內存空間（基本類型除外），所有對象均在堆中分配空間。而對象的釋放則由垃圾收集器（GC）自動決定並執行。這種「分配由程式完成，釋放由 GC 負責」的雙軌制模式，雖然大幅簡化了開發者的工作，但也增加了 JVM 的負擔，這也是 Java 程式執行速度相對較慢的原因之一。因為 GC 為了精確釋放對象，必須持續監控每個對象的運行狀態，包括申請、引用、被引用、賦值等操作。
為了更好理解 GC 的工作原理，可以將對象視為有向圖的頂點，引用關係視為有向邊（從引用者指向被引用對象）。每個線程對象可作為圖的起始頂點，例如大多數程式從 main 線程開始執行，便形成一棵以 main 為根的樹。在這個有向圖中，根頂點可達的對象均為有效對象，GC 不會回收它們；若某個對象（或連通子圖）與根頂點不可達，則判定為不再被引用，可被 GC 回收。
Java 採用有向圖方式管理內存，可有效消除引用循環問題。例如三個對象相互引用，只要它們與根進程不可達，GC 依然能回收它們。此方式管理精度高，但效率較低。另一種常見技術是引用計數器（如 COM 模型），執行效率高，但難以處理循環引用，精度較低。
在 Java 中，內存洩漏是指存在已分配的對象，同時滿足兩個條件：一是可達的（有向圖中存在路徑可連接）；二是無用的（程式後續不再使用）。這類對象不會被 GC 回收，卻持續佔用內存。與 C++ 不同，C++ 中不可達對象因無 GC 而永遠無法回收，屬於更廣泛的內存洩漏；Java 語言層面保證所有對象可達，不可達對象由 GC 管理，因此 Java 內存洩漏範圍較小。對程式設計師而言，只需管理引用（邊），無需管理對象釋放（頂點），提升了編程效率。
GC 對程式設計師基本透明。雖有 System.gc() 等函數，但 Java 語言規範不保證 JVM 垃圾收集器一定執行。不同 JVM 實現可能採用不同算法，GC 線程優先級通常較低，觸發策略多樣（內存達臨界值、定時、平滑、中斷式等）。一般情況下無需關心，除非特定場景（如 Web 實時系統、網絡遊戲）GC 突然中斷影響性能，需調整 GC 參數，採用平滑方式釋放內存（如將垃圾回收分解為小步驟），Sun HotSpot JVM 支持此特性。
典型案例：循環創建 Object 對象並放入 Vector，僅釋放引用本身（o=null），但 Vector 仍引用該對象，導致 GC 無法回收。解決方法是從 Vector 中刪除對象，或將 Vector 設置為 null。
Vector v = new Vector(10);
for (int i = 1; i < 100; i++) {
Object o = new Object();
v.add(o);
o = null;
}
// 此時所有 Object 對象未被釋放，因變量 v 仍引用它們
對象游離是指對象雖仍被引用，但程式不再使用。例如將緩衝區從局部變量提升為實例字段以減少內存分配，看似優化，實則可能導致對象長期佔用內存，且破壞線程安全。直觀實現（局部變量）不需同步，並發擴展性更好。對象分配成本往往比預期低，過度優化反而引入問題。
