Java 記憶體洩漏排查實戰：用 JProbe 找出 OutOfMemoryError 真兇

Swing 桌面應用頻繁開關子視窗導致 `java.lang.OutOfMemoryError`，經 JProbe 8.0 深度分析，鎖定三大洩漏源頭：靜態集合持有引用、線程未正確終止、事件監聽器未解除註冊。本文完整記錄排查流程與修復方案。

工具鏈與環境準備

1. JProbe Config：生成監控腳本 (`.jpl` + `.bat`)，命令列啟動目標應用
2. JProbe Console：Attach to Session 開啟即時監控面板 `Runtime Summary`
3. 關鍵操作：`Refresh Runtime Data` 更新物件統計，`Request a Garbage Collection` (垃圾桶圖標) 強制觸發 GC

排查核心邏輯

1. 鎖定可疑類別 (如子視窗類)
2. 操作觸發建立/銷毀流程 (開啟/關閉視窗)
3. 點擊 `Request a Garbage Collection` 強制 GC
4. 點擊 `Refresh Runtime Data` 觀察該類別實例計數是否歸零
5. 若計數不降，該類別存在引用洩漏 — 90% 確信是真兇

三大洩漏模式與修復方案

1. 靜態集合 (HashMap/Hashtable) 持有殭屍引用

現象：靜態 `Map` 未調用 `remove(key)`，鍵值對永久駐留

修復：

// 使用完畢後
map.remove(key);        // 精確移除
map.clear();            // 清空整個 Map
map = null;             // 釋放 Map 本身引用 (最徹底)

原則：靜態集合謹慎使用，必須有明確清理策略。

2. 線程未正確終止導致物件無法回收

誤區：單純 `thread.join()` 等待不足以保證回收，若線程曾 `sleep()` 後 `join()` 可能卡住

正確模式：`interrupt()` + 開關變數 + `join()`

public void stopThread() {
  try {
    ifForceInterruptThread = true;   // 開關變數
    isThreadAlive = false;
    logThread.t.interrupt();         // 打斷 sleep/wait
    logThread.t.join(50);            // 等待終止
  } catch (InterruptedException ex) {
    // 忽略
  } finally {
    controlList = null;
    keyList = null;
    logThread = null;
  }
}

// 線程 run() 內部
try {
  while (isThreadAlive) {
    startMonitor();
    Thread.sleep(interval);
  }
} catch (InterruptedException e) {
  if (!ifForceInterruptThread) {     // 正常業務中斷 vs 強制關閉
    // 記錄錯誤、嘗試重啟
  }
}

3. 事件監聽器未解除註冊 (Swing 視窗典型問題)

現象：`JFrame` 子視窗 `dispose()` 後，匿名內部類監聽器仍被事件源持有

修復：

• 初始化時設定 `setDefaultCloseOperation(DISPOSE_ON_CLOSE)`
• 所有監聽器改為 非靜態內部類，隨外部類實例銷毀而回收
• 或顯式調用 `removeXxxListener()` 清理

JProbe 實戰心法

• 耐心是關鍵：一次完整排查可能耗費數小時
• 多次驗證：操作→強制 GC→刷新，重複 3-5 次確認
• 關注增量：對比操作前後實例計數變化，而非絕對值
• 源碼對照：定位洩漏類別後，閱讀代碼尋找持有引用處

預防清單

1. 靜態集合：定期清理、弱引用 (`WeakHashMap`)、生命週期綁定
2. 線程池：使用 `ExecutorService` 統一管理，避免手動線程控制
3. 監聽器：內部類、弱引用監聽器 (`WeakReference`)、統一註冊/註銷管理器
4. 資源關閉：`try-with-resources` (Java 7+)、`finally` 區塊確保 `close()`