IBM i JVM 記憶體模型深度解析：Break Memory 與 Heap Memory 關係與排錯實戰

前言：32 位元與 64 位元 JVM 的抉择

IBM i 開發者常面臨選擇：32 位元 JVM 啟動快、執行快、資源佔用少，但可定址記憶體遠小於 64 位元版本。若應用程式記憶體需求超出 32 位元上限，便被迫遷移至 64 位元 JVM。要精準評估記憶體需求，必須先理解 IBM i JVM 獨特的記憶體結構——Java Heap 與 Break Memory 的劃分與互動。

一、什麼是 Break Memory？

相對於受 GC 管理的 Heap Memory，Break Memory（又稱內部/私有記憶體）是 JVM 透過 C/C++ malloc 直接向作業系統申請的原生記憶體，主要供以下組件使用：

• 執行緒堆疊
• JVM 內部 C/C++ 程式碼
• 使用者 Native 方法（JNI）與 PASE Native 函式

二、32 位元記憶體空間佈局與三種模式

32 位元程式共擁 4 GB 位址空間（16 個 256 MB 分區）。Heap 與 Break Memory 共享 0x3–0xC 分區，且總額固定：Heap 預留越多，Break Memory 可用越少。

2.1 標準模式（-Xmx ≤ 2304 MB）

• Heap 佔用 0xC–0xF（高位址向下擴展）
• Break Memory 從 0x3 向上分配
• 預設 -Xmx=2GB：Heap 8 區塊（2048 MB），系統保留 6 區塊，Break Memory 僅 2 區塊（512 MB）
• 設 -Xmx=1500MB：Heap 6 區塊，Break Memory 4 區塊（1024 MB）

圖 1. 標準模式記憶體佈局

2.2 大 Heap 模式（2304 MB < -Xmx ≤ 3072 MB）

Heap 佔用 0x7–0xF 固定 9 區塊，並與 Break Memory 共享 0x3–0x6 區塊。

圖 2. 大 Heap 模式記憶體佈局

2.3 超大 Heap 模式（-Xmx > 3072 MB）

Heap 獨佔 0x3–0xF 共 13 區塊（3328 MB，32 位元極限），Break Memory 與主執行緒堆疊擠在 0x2 區塊（256 MB）。

圖 3. 超大 Heap 模式記憶體佈局

三、估算 Break Memory 需求

執行緒堆疊是 Break Memory 主要消耗者。假設每執行緒需 260 KB，可根據 -Xmx 設定推估可支援執行緒數上限：

Break Memory 可用空間與最大執行緒數對應關係

四、監控 Break Memory 使用情況

4.1 V5R4：JVMINFO -memory <taskid>

使用 STRSST → Advanced Analysis → JVMINFO -memory 查看詳細 Break Memory 分配。

圖 4. JVMINFO 輸出範例

4.2 V6R1+：WRKJVMJOB → Display Garbage Collection Information

圖形化介面直接顯示 Break Memory 大小與使用趨勢。

圖 5. WRKJVMJOB 輸出範例

五、Break Memory 不足的徵兆與排查策略

5.1 不同版本的表現差異

5.2 判斷「洩漏」還是「空間不足」

1. 調小 -Xmx 釋放更多 Break Memory 空間。
2. 觀察一段時間：
   • 使用量持續上升 → 疑似 Native 記憶體洩漏（JNI/第三方庫）。
   • 使用量趨穩 → 純屬空間不足，調整 -Xmx 即可解決。
3. 精準定位洩漏：啟動選項 MALLOCDEBUG=report_allocations 記錄所有 malloc 呼叫點。

5.3 終極對策：遷移至 64 位元 JVM

若減小 Heap 導致 Heap 本身 OOM，說明 32 位元位址空間已耗盡，唯有改用 64 位元 JVM 徹底解決。

結語

本文剖析了 IBM i JVM 記憶體模型、Break Memory 分佈規律、監控工具與排錯路徑。Java 記憶體管理博大精深，掌握基礎後仍需持續深入鑽研，方能應對生產環境的複雜挑戰。