Java 堆與棧記憶體存儲機制深度解析與 OOM 故障排查

前言

Java 自動記憶體管理雖減輕開發者負擔，但不理解堆與棧的存儲差異、物件生命週期、GC 行為，極易遭遇 OutOfMemoryError 或效能抖動。本文系統解析記憶體模型、參數調優、OOM 類型診斷、String 常量池機制，並提供生產級排查工具鏈。

一、堆與棧：核心差異對照

二、JVM 記憶體區域與參數調優

2.1 核心參數

2.2 實際配置範例

# JVM 參數 (catalina.sh / eclipse.ini / 啟動腳本)
-Xms2g -Xmx2g -Xmn1g -Xss512k
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heapdump.hprof

2.3 運行時監控 API

Runtime rt = Runtime.getRuntime();
long max = rt.maxMemory();      // -Xmx
long total = rt.totalMemory();  // 當前已向 OS 申請
long free = rt.freeMemory();    // 當前可用
long used = total - free;       // 實際佔用

三、堆結構與 GC 分代機制

3.1 邏輯分區

• 新生代：Eden + Survivor (S0/S1)，短命物件誕生地，Minor GC 頻繁、快速。
• 老年代：長命物件晉升區，Major/Full GC 觸發、耗時長。
• 元空間：類元數據、常量池、靜態變數（JDK 8+ 移出堆，使用本地記憶體）。

3.2 物件分配流程

1. 優先在 Eden 分配（TLAB 優化）。
2. 大物件（-XX:PretenureSizeThreshold）直接進老年代。
3. 長期存活（年齡達 -XX:MaxTenuringThreshold，預設 15）晉升老年代。
4. 動態年齡判斷：Survivor 同齡物件總大小 > Survivor 一半，直接晉升。
5. 空間擔保：Minor GC 前檢查老年代連續空間是否足夠容納所有新生代物件，不足則觸發 Full GC。

四、OOM 故障分類與診斷

五、String 常量池與棧/堆交互實證

5.1 字面量 vs new String()

String s1 = "abc";        // 檢查常量池，無則建立並入池，參考指向池中物件
String s2 = "abc";        // 直接指向池中同一物件 → s1 == s2 為 true
String s3 = new String("abc"); // 堆中建立新物件，內容複製自常量池 → s1 == s3 為 false
String s4 = new String("abc"); // 又一個堆物件 → s3 == s4 為 false

5.2 intern() 手動入池

String s5 = new String("abc").intern(); // 若池有 "abc" 回傳池引用，否則放入池並回傳
// s5 == s1 → true

5.3 執行期常量池擴充

JDK 7 起常量池移至堆中，String.intern() 效能大幅提升，但大量調用仍可能導致 Metaspace/堆壓力。

5.4 最佳實務

• 頻繁拼接字串使用 StringBuilder/StringBuffer（避免產生大量中間物件）。
• 避免不必要的 new String()。
• 大量固定字串（如狀態碼、配置鍵）可考慮 enum 或 intern() 節省記憶體。

六、生產級排查工具鏈

1. 即時監控：JConsole、VisualVM、JMC (Java Mission Control)、Prometheus + JMX Exporter + Grafana。
2. Heap Dump 分析：jmap -dump:live,format=b,file=heap.hprof <pid> → MAT (Eclipse Memory Analyzer) / JHat / VisualVM 分析支配者樹、洩漏疑點。
3. GC 日誌分析：-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags (JDK 9+) → GCeasy、GCEasy.io、GCViewer 可視化。
4. 線程快照：jstack <pid> > threaddump.txt 分析死鎖、CPU 高佔用線程。
5. Arthas / BTrace：線上動態追蹤方法耗時、參數、回傳值、觀察物件創建堆疊。

七、總結

• 堆存物件、棧存參考與基本型別，理解差異是寫出高效代碼的前提。
• OOM 多為記憶體洩漏或配置不當，Heap Dump + MAT 是定位洩漏的黃金組合。
• String 常量池機制影響 == 與 equals() 行為，慎用 new String()。
• 建立完整的 JVM 參數基線、GC 日誌歸檔、定期 Heap Dump 機制，做到有備無患。