JVM 記憶體與 GC：從分代假說到容器裡的 OOMKilled

很多人以為 -Xmx 就是 JVM 的記憶體上限。它只管其中一塊。這個誤解是後面「容器被 OOMKilled」的根源，所以先把地圖攤開。

受 -Xmx 管的：只有 Heap

• Heap（堆）——所有 new 出來的物件都在這裡，也是 GC 的主戰場。分成新生代與老年代。

不受 -Xmx 管的（但一樣佔實體記憶體）

• Metaspace——類別的中繼資料（Class 結構、方法資訊）。JDK 8 之後放在原生記憶體，預設沒有上限，由 -XX:MaxMetaspaceSize 控制。
• 執行緒堆疊（Thread Stack）——每條執行緒各一份，預設 512KB～1MB（-Xss）。1000 條執行緒就是接近 1GB。
• Direct Memory（堆外記憶體）——NIO 的 ByteBuffer.allocateDirect()、Netty、部分 JDBC 驅動都會用。由 -XX:MaxDirectMemorySize 控制，預設等於 -Xmx。
• Code Cache——JIT 編譯後的機器碼。
• GC 自身的資料結構——記憶集、標記位圖等，G1 大約要 heap 的 5～10%。

快速估算

RSS ≈ Xmx
     + Metaspace（一般 Spring Boot 約 100～256MB）
     + 執行緒數 × Xss（200 條 × 1MB ＝ 200MB）
     + Direct Memory（視使用情況）
     + Code Cache（約 50～100MB）
     + GC 結構（Xmx 的 5～10%）

「新生代、老年代、Eden、Survivor、8:1:1」——這些名詞如果用背的，很快就會忘。它們全部都是從一個觀察推導出來的。

那個觀察：弱世代假說（Weak Generational Hypothesis）

想想你寫的程式碼就知道：一個 HTTP 請求進來，建了 DTO、建了字串、建了一堆中間集合，回應送出去之後這些全部都沒用了。真正需要長期存活的東西（快取、連線池、單例 Bean）非常少。

從這個觀察能推出什麼

如果 98% 的物件都會死，那麼「找出還活著的那 2%」遠比「找出死掉的那 98%」便宜。

這正是複製演算法（Copying）的前提：

把記憶體切兩半，只用其中一半。
GC 時：把「還活著的物件」複製到另一半，然後整塊清空原來那半。

成本 ∝ 存活物件的數量（很少）
而不是 ∝ 垃圾的數量（很多）

• ✅ 不會產生記憶體碎片（複製過去時直接緊密排列）
• ✅ 配置新物件時只要移動一個指標（bump the pointer），極快
• ❌ 浪費一半空間

8:1:1 是怎麼來的

「浪費一半」太奢侈了。既然只有 2% 會活下來，根本不需要留 50% 當作複製的目的地——留 10% 就夠了。

新生代 ＝ Eden 80%  +  Survivor 0 (10%)  +  Survivor 1 (10%)

平常只用 Eden + 一個 Survivor（共 90%）
GC 時把活著的複製到另一個 Survivor（10%）

那老年代呢

能活過好幾輪 GC 的物件，很可能會活很久。對這些物件用複製演算法就不划算了（存活率高＝複製成本高），所以老年代改用標記-整理（Mark-Compact）：標記出活的，然後把它們往一端推擠、整理碎片。

把上一張卡的推導接起來，看一個物件實際會走過的路徑。

第 1 步：在 Eden 出生

幾乎所有物件都在 Eden 配置。配置的動作只是移動一個指標，所以極快（比 C 的 malloc 還快）。

第 2 步：Eden 滿了 → 觸發 Young GC（Minor GC）

Eden 中還活著的物件  →  複製到 Survivor 0，年齡 +1
Eden 整塊清空（不需要逐一釋放）

第 3 步：之後的每次 Young GC

Eden 活著的 + Survivor 0 活著的  →  一起複製到 Survivor 1，年齡 +1
然後 Eden 與 Survivor 0 整塊清空

下一輪換方向：複製到 Survivor 0
（所以兩個 Survivor 永遠有一個是空的）

第 4 步：晉升老年代（Promotion）

有四種情況會讓物件搬進老年代：

1. 年齡達標——熬過 -XX:MaxTenuringThreshold 次 GC（預設 15）
2. 動態年齡判定——如果同一年齡的物件總大小超過 Survivor 的一半，那個年齡以上的全部直接晉升，不用等到 15
3. 大物件直接晉升——超過 -XX:PretenureSizeThreshold 的物件直接進老年代（避免在 Survivor 之間反覆複製）
4. Survivor 放不下——空間不足時直接進老年代（稱為「分配擔保」）

第 5 步：老年代滿了 → Full GC

Full GC 會同時整理新生代與老年代，停頓時間比 Young GC 長一到兩個數量級。這就是下一張卡的主題。

GC 最重要的指標不是「回收了多少記憶體」，而是它讓你的程式停了多久。

什麼是 STW（Stop-The-World）

GC 需要在某些階段暫停所有應用執行緒——因為它要移動物件、更新參照，過程中不能有人偷改。這段時間你的服務完全沒有回應：不處理請求、不回心跳、不讀 socket。

• Young GC：通常 1～50 毫秒，頻繁但可接受
• Full GC：舊的收集器可能好幾秒，heap 越大越久

一次 2 秒的 Full GC 會發生什麼（連鎖反應）

① GC 開始，所有應用執行緒暫停 2 秒

② 已經借出去的資料庫連線「被凍在半路」
   → 連線沒有還回池裡（ch03）
   → 新進來的請求全部卡在等連線

③ Tomcat 執行緒池被塞滿
   → 新的 HTTP 請求開始排隊，甚至被拒絕

④ 上游服務的呼叫逾時 → 觸發重試
   → 重試讓流量瞬間放大 2～3 倍

⑤ GC 結束，服務恢復——但此時面對的是「原本的流量 + 累積的積壓 + 重試放大」
   → 記憶體壓力更大 → 觸發下一次 Full GC

⑥ 進入 GC 死亡螺旋

現代收集器怎麼解決

• G1（JDK 9 起的預設）——把 heap 切成數千個 region，每次只回收「垃圾最多的幾個 region」（Garbage First 的由來），用 -XX:MaxGCPauseMillis 給一個停頓目標，G1 自己決定這次收幾個 region。
• ZGC / Shenandoah——標記與整理幾乎全部並行執行，停頓時間與 heap 大小無關，通常在 1 毫秒以內。代價是吞吐量略低、CPU 用得多一些。

GC 判斷「這個物件還要不要」的依據是「還有沒有人參照它」。但參照有強弱之分——這是 Java 少數幾個「你可以直接干預 GC」的地方。

強引用（Strong）——預設的那種

User user = new User();   // 強引用

只要強引用還在，GC 絕對不會回收它——寧可拋 OutOfMemoryError 也不動。

軟引用（Soft）——記憶體不夠時才回收

SoftReference<byte[]> cache = new SoftReference<>(bigData);

記憶體充足時保留，快要 OOM 之前才回收。天生適合做快取——記憶體夠就留著，不夠就自動讓出。

弱引用（Weak）——下一次 GC 就回收

WeakReference<User> ref = new WeakReference<>(user);

只要發生 GC 就會被回收，不管記憶體夠不夠。ThreadLocalMap 的 key 就是弱引用——這是下面那個經典洩漏的關鍵。

虛引用（Phantom）——只用來收屍

完全拿不到物件本身，唯一用途是在物件被回收時收到通知，用來管理堆外資源（例如 DirectByteBuffer 的釋放）。一般業務程式碼不會用到。

ThreadLocal 記憶體洩漏：真正的原因

ThreadLocalMap 的結構：
  key   = ThreadLocal 物件的「弱引用」
  value = 你放進去的東西的「強引用」   ← 問題在這

1. ThreadLocal 變數本身沒人參照了 → key 被 GC 回收，變成 null
2. 但 value 是強引用，還掛在 ThreadLocalMap 上
3. ThreadLocalMap 屬於 Thread → 只要那條執行緒還活著，value 就永遠不會被回收

字串是 Java 裡最常被建立的物件，所以 JVM 為它做了特別處理——也因此產生了最多的誤解。

常量池在哪裡

• JDK 6 以前：在永久代（PermGen），空間小，intern() 太多會 OutOfMemoryError: PermGen space
• JDK 7 之後：移到 Heap 裡，所以可以被 GC 回收，也受 -Xmx 管
• JDK 8：永久代整個廢除，換成 Metaspace（放類別中繼資料），字串常量池仍在 Heap

字面量 vs new String()

String a = "hello";              // 直接指向常量池裡的物件
String b = "hello";              // 指向「同一個」常量池物件
String c = new String("hello");  // 在 heap 新建一個物件，內容相同但位址不同

a == b        // true   ← 同一個物件
a == c        // false  ← 不同物件
a.equals(c)   // true   ← 內容相同

編譯期常量折疊

String a = "hello";
String b = "hel" + "lo";        // 編譯器直接算成 "hello" → a == b 為 true

String hel = "hel";
String c = hel + "lo";          // 執行期才拼接 → 新物件 → a == c 為 false

迴圈裡拼接字串為什麼慢

// ❌ 每一圈都產生一個新的 String 物件
String result = "";
for (String s : list) { result += s; }

// ✅ 只有一個可變的緩衝區
StringBuilder sb = new StringBuilder();
for (String s : list) { sb.append(s); }

String 是不可變的，+= 實際上是建新物件再丟掉舊的。一萬圈就產生一萬個垃圾物件——這正是新生代 GC 的主要來源之一。

OutOfMemoryError 後面那串字才是重點——五種訊息代表五個完全不同的問題，修法也完全不同。

1. Java heap space

最常見。物件塞不進 heap 了。

• 可能是真的不夠：流量成長、快取設太大 → 調 -Xmx
• 可能是記憶體洩漏：某個集合只進不出、ThreadLocal 沒清、監聽器沒移除 → 調大只是延後爆炸時間
• 診斷：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump，用 MAT 或 VisualVM 開 dump，看「誰佔最多、誰參照著它」

2. GC overhead limit exceeded

JVM 花了超過 98% 的時間在 GC，卻只回收到不到 2% 的記憶體。本質上就是 heap space 的前兆——記憶體幾乎全是活的物件，GC 一直做白工。診斷方式相同。

3. Metaspace

類別中繼資料放不下。正常應用不會發生，發生了通常代表：

• 動態產生類別（CGLIB 代理、Groovy 腳本、大量反射）沒有節制
• 應用程式重複熱部署，舊的 ClassLoader 沒被回收

4. Direct buffer memory

堆外記憶體用完。Netty、NIO、某些 JDBC 驅動會用。-Xmx 調大完全沒用，要調的是 -XX:MaxDirectMemorySize，或者找出沒有釋放 ByteBuffer 的地方。

5. unable to create new native thread

這個根本不是記憶體不足，是執行緒數量到頂了。可能是 OS 的 ulimit -u 限制，也可能是執行緒洩漏（每次請求都 new Thread() 而沒有用執行緒池）。

這是容器化之後最典型、也最難查的一種死法——因為它不留下任何 Java 層面的證據。

徵狀

• Pod 突然重啟，kubectl describe pod 顯示 Reason: OOMKilled、Exit Code: 137
• 應用程式 log 裡什麼都沒有——沒有例外、沒有 heap dump、沒有 GC log 的異常
• 最後一行 log 可能只是一個正常的請求處理完成

原因一：RSS 超過容器限制（最常見）

回到第一張卡：JVM 佔用的實體記憶體遠大於 -Xmx。

容器 memory limit: 2Gi
-Xmx2g                     ← 看起來剛剛好

實際 RSS:
  Heap          2.0 GB
+ Metaspace     0.2 GB
+ 執行緒堆疊     0.2 GB   （200 條 × 1MB）
+ Code Cache    0.1 GB
+ GC 結構       0.15 GB
= 約 2.65 GB   ← 超過 2Gi，被殺

原因二：JVM 看不到容器的限制（舊版本）

JVM 預設會把 heap 設成「實體記憶體的 1/4」。JDK 8u191 以前的版本讀到的是「宿主機」的記憶體，不是容器的 limit：

宿主機 64GB，容器 limit 2GB
舊 JDK：預設 -Xmx ＝ 64GB / 4 ＝ 16GB
→ JVM 開心地一直配置到 16GB → 早就被 cgroup 殺掉了

修法

# ① 用百分比而不是絕對值（JDK 10+，會讀容器 limit）
-XX:MaxRAMPercentage=70.0

# ② 明確限制非 heap 的部分
-XX:MaxMetaspaceSize=256m
-Xss512k                      # 執行緒多的話特別有效
-XX:MaxDirectMemorySize=256m

# ③ 確認 JVM 有看到容器限制（JDK 10+ 預設開啟）
-XX:+UseContainerSupport

怎麼確認 JVM 看到的是什麼

java -XX:+PrintFlagsFinal -version | grep -E 'MaxHeapSize|MaxRAMPercentage'

# 在容器裡直接問 JVM
jcmd <pid> VM.flags
jcmd <pid> VM.native_memory summary   # 需要 -XX:NativeMemoryTracking=summary

GC 調校是最容易「看起來很專業，實際上在瞎忙」的領域。先講一個殘酷的事實：

先量再調，而且要量對東西

# 開 GC log（JDK 9+ 統一格式）
-Xlog:gc*:file=/var/log/gc.log:time,uptime:filecount=5,filesize=10M

# 要看的三個數字：
#   ① Full GC 的「頻率」——一小時幾次？
#   ② 每次停頓「多久」——P99 是多少？
#   ③ Full GC 之後老年代「降到多少」——降不下來就是洩漏

不要做的事

• 不要抄別人的參數。網路上那些「JVM 調優黃金參數」是為特定的硬體、heap 大小、應用型態調的。抄過來很可能更差。
• 不要一次改多個參數。改了三個東西之後變快了，你不知道是哪一個有效，也不知道另外兩個是不是反而有害。
• 不要在沒有 GC log 的情況下調參數。那是猜，不是調。
• 不要因為「Full GC 很可怕」就把 heap 開很大。heap 越大，單次 Full GC 的停頓越長。

真正常用的參數其實只有幾個

• -Xmx / -XX:MaxRAMPercentage——最重要的一個
• -XX:MaxGCPauseMillis——給 G1 一個停頓目標（不保證達成，但它會朝這個方向調）
• -XX:+HeapDumpOnOutOfMemoryError——這個一定要開，出事時才有證據
• 對延遲極度敏感時：換 ZGC（-XX:+UseZGC）

正確的排查順序

1. 看完整的 OOM 訊息 → 確認是哪一種 OOM（五種修法完全不同）
2. 看 GC log → Full GC 後老年代降不下來？那是洩漏，去抓 heap dump
3. heap dump 裡看 dominator tree → 誰佔最多、誰參照著它
4. 修掉洩漏或不合理的快取
5. 以上都做完了、確認記憶體用量合理，才輪到調 GC 參數

這個順序跟 ch03 的「先看 SQL → 再看交易邊界 → 最後才調池」是同一個道理：先找根因，再調旋鈕。