JVM GC 調優實戰：從「巨蟒吞豬」看堆記憶體配置對吞吐量的顛覆性影響

前言：巨蟒吞豬的隱喻

「Pig in the Python」形容 GC 將大物件在分代間頻繁搬移，導致 JVM 消化不良、停頓劇增。本文透過一個模擬「巨蟒吞豬」的實驗，揭示較小堆 + 較大新生代 + Parallel GC 竟比大堆 + 大老年代 + CMS 吞吐量高 12% 的反直覺結果。

實驗場景：PigInThePython

public class PigInThePython {
    static volatile List pigs = new ArrayList<>();
    static volatile int pigsEaten = 0;
    static final int ENOUGH_PIGS = 5000;

    // 生產者：每 100ms 吞入 32MB「豬」
    static class PigEater extends Thread {
        public void run() {
            while (true) {
                pigs.add(new byte[32 * 1024 * 1024]);
                if (pigsEaten > ENOUGH_PIGS) return;
                sleep(100);
            }
        }
    }

    // 消費者：每 2 秒消化一次（清空列表）
    static class PigDigester extends Thread {
        public void run() {
            long start = System.currentTimeMillis();
            while (true) {
                sleep(2000);
                pigsEaten += pigs.size();
                pigs = new ArrayList<>();  // 丟棄舊列表，產生大量垃圾
                if (pigsEaten > ENOUGH_PIGS) {
                    System.out.format("Digested %d pigs in %d ms.%n", pigsEaten, System.currentTimeMillis()-start);
                    return;
                }
            }
        }
    }
}

理論最大吞吐量：10 隻/秒（100ms/隻）。

兩組 JVM 參數對決

GC 日誌深度剖析

Config 1：CMS + 大老年代

jstat -gc -t -h20 PID 1s
# 統計：1129 次 GC，總暫停 63.7 秒
Timestamp  S0C      S1C      ...  YGC   YGCT    FGC  FGCT     GCT
594.0      174720   174720   ...  1006  63.182  116  0.236    63.419
595.0      174720   174720   ...  1008  63.310  117  0.236    63.546
...

• 頻繁 Young GC（1000+ 次）+ 可觀 Full GC（116 次）
• 老年代佔用高（~2.6GB），CMS 併發標記/清理開銷大

Config 2：Parallel GC + 巨大新生代

# 統計：168 次 GC，總暫停 11.4 秒
Timestamp  S0C      S1C      ...  YGC  YGCT   FGC  FGCT    GCT
539.3      164352   164352   ...  27   2.969  141  8.441   11.409
...

• Young GC 僅 27 次，Full GC 141 次但總暫停極短
• 新生代 1.5GB，Eden 足夠大，32MB 豬直接在 Eden 分配、死亡，Young GC 高效清理
• 物件幾乎不進老年代，避免 CMS 處理長期存活物件的負擔

核心結論

1. 物件壽命極短時，大新生代 + Parallel GC 碾壓 CMS：Parallel GC 多執行緒複製極快，CMS 併發階段反而成負擔。
2. 堆越大不代表效能越好：Config 2 堆減半、吞吐量反升，關鍵在於新生代佔比與物件存活特性匹配。
3. GC 調優無銀彈：必須理解應用物件生命週期（朝生夕死 vs 長期存活），選對收集器與分代比例。

實務建議

• 用 jstat -gc / GCLogAnalysis 觀察 YGC/FGC 頻率與暫停
• 短命物件多 → 增大 -Xmn、用 Parallel/ParallelOld/G1
• 長命物件多、低延遲要求 → CMS/ZGC/Shenandoah + 適當老年代
• 生產環境建議接入 Plumbr、Arthas、Async Profiler 做持續觀測

結語

這條「抽風的巨蟒」提醒我們：GC 調優是門需深入理解底層機制的手藝活。同樣的業務邏輯，參數微調可能帶來數倍效能差距。與其盲目複製網上參數，不如建立觀測 → 假設 → 驗證 → 固化的調優閉環，讓 JVM 真正為業務加速。