Java 記憶體溢位 (OOM) 完整解析：類型、原因、JVM 調優與程式碼級優化

一、常見 OOM 類型與成因

1. java.lang.OutOfMemoryError: PermGen space (JDK 7 及之前)

• 區域：永久代，存放類元資料、常數池、靜態變數、即時編譯器產生的程式碼緩存。
• 成因：載入過多類（大量 JSP、第三方 JAR、動態產生類）、熱部署未清理舊類載入器、-XX:MaxPermSize 設定過小。
• 解決：增大 -XX:PermSize=128M -XX:MaxPermSize=256M；JDK 8+ 已移除永久代，改用 Metaspace（本機記憶體），需調整 -XX:MaxMetaspaceSize。

2. java.lang.OutOfMemoryError: Java heap space

• 區域：Java 堆積，存放所有物件實例與陣列。
• 成因：物件創建過快/過多、記憶體洩漏（長生命週期物件持有短命物件引用）、-Xmx 設定過小、大物件直接進老年代觸發頻繁 Full GC。
• 預設值：-Xms 物理記憶體 1/64，-Xmx 1/4（32 位 JVM 受限 1.5~3GB）。

二、JVM 記憶體區域組成與 GC 機制

堆積分代結構

• 新生代：Eden + Survivor0 + Survivor1。新物件優先分配在 Eden，Minor GC 存活物件複製到 Survivor，經歷多次仍存活者晉升老年代。
• 老年代：存放長期存活物件。空間不足觸發 Full GC（STW，停頓時間長）。
• 永久代/元空間：類元資料。

GC 觸發條件

1. 應用執行緒閒置時（安全點）。
2. 堆積空間不足（Allocation Failure）。
3. 顯式呼叫 System.gc()（僅建議，不保證立即執行）。

避坑指南：頻繁 Full GC 通常意味著老年代空間不足或記憶體洩漏，需配合工具分析而非盲目增大堆積。

三、JVM 關鍵參數調優速查表

參數	含義	建議值/備註
-Xms	初始堆積大小	設定等於 -Xmx，避免動態伸縮開銷
-Xmx	最大堆積大小	物理記憶體 60%~80%，預留給 OS、Metaspace、線程棧、直接記憶體
-Xmn	新生代大小	約 -Xmx 1/4~1/3，過大導致老年代過小頻繁 Full GC
-XX:PermSize / -XX:MaxPermSize	永久代初始/最大值 (JDK7-)	128M / 256M 起步，視類載入量調整
-XX:MaxMetaspaceSize	元空間最大值 (JDK8+)	建議設定上限，防止無限增長耗盡本機記憶體
-Xss	線程棧大小	256K~512K 通常足夠，過大減少可建立線程數
-XX:+UseConcMarkSweepGC / -XX:+UseG1GC	GC 收集器選擇	JDK8 建議 G1；大堆積低延遲首選 ZGC/Shenandoah (JDK11+)

Tomcat 啟動腳本範例 (catalina.sh/bat)

JAVA_OPTS="-server -Xms2g -Xmx2g -Xmn512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/logs/heapdump.hprof"

四、效能診斷工具鏈

| 工具 | 定位 | 適用場景 | |------|------|----------| | jstat -gcutil | GC 頻率、各代佔用、停頓時間 | 線上快速巡檢，無侵入 | | jmap -histo:live <pid> | 存活物件統計（類、數量、大小） | 定位大物件、洩漏候選者 | | jmap -dump:format=b,file=heap.bin <pid> | 完整堆積快照 | 離線深度分析，**生產環境謹慎使用（STW）** | | Eclipse MAT / JVisualVM | 堆積轉儲分析、支配者樹、洩漏報告 | 圖形化深度剖析，找出 GC Roots 連結路徑 | | JProfiler / Arthas | 即時記憶體監控、物件分配記錄、線程剖析 | 開發/測試環境全方位診斷 |

五、程式碼層面的七大防洩漏/防 OOM 守則

1. 及時釋放引用：方法局部變數自然隨棧幀銷毀；集合/快取需手動 remove 或設 null，特別是靜態集合。
2. 慎用 String 拼接：循環中用 StringBuilder/StringBuffer，避免產生大量中間 String 物件佔滿新生代/常數池。
3. 減少 static 欄位：靜態變數生命週期 = 類載入器生命週期，GC 不回收，易成洩漏源頭。
4. 避免集中創建大物件/大陣列：如 byte[] buf = new byte[request.getContentLength()] 若請求體極大直接 OOM。改用分塊讀取、流式處理、臨時檔案。
5. 物件池技術：頻繁創建銷毀的昂貴物件（資料庫連線、執行緒、大緩衝區）使用池化復用。
6. 大集合分批處理：一次性從 DB 拉取十萬條資料放 List 易 OOM。採用游標/分頁/流式處理，處理完一批釋放一批。
7. 避免在熱點方法/迴圈中 new 物件：改用物件復用、ThreadLocal、對象池。

六、實戰案例：檔案上傳 OOM

// 問題代碼
m_totalBytes = m_request.getContentLength(); // 假設 2GB
m_binArray = new byte[m_totalBytes];         // 直接分配 2GB 連續堆積空間 → OOM

// 解決方案：流式處理
try (InputStream in = request.getInputStream();
     FileOutputStream out = new FileOutputStream(tempFile)) {
    byte[] buffer = new byte[8192];
    int len;
    while ((len = in.read(buffer)) > 0) {
        out.write(buffer, 0, len);
    }
}

七、總結檢查清單

• ☐ 確認 -Xms/-Xmx 設定合理且相等
• ☐ 新生代/老年代比例適當（-Xmn）
• ☐ Metaspace/PermGen 上限已設定
• ☐ 啟用 HeapDumpOnOutOfMemoryError 保留現場
• ☐ 程式碼無靜態集合洩漏、無大物件集中分配、無迴圈 String 拼接
• ☐ 定期用 jstat/MAT 巡檢 GC 行為與物件佔用

記憶體調優無銀彈，核心在於理解物件生命週期、選對 GC 收集器、建立可觀測體系。遇到 OOM 先 Dump 再分析，對症下藥才是正道。