JVM 动态扩容引起的空间震荡

空间震荡

一次 Young GC 后，Eden 竟“跳回” 512 MB？

先看一段来自生产环境的 GC 日志（G1，JDK 17）：

[gc,heap] GC(123) Pause Young (Normal) (G1 Evacuation Pause)
[gc,heap] Eden regions: 737->0(221)
[gc,heap] Survivor regions: 37->37(221)
[gc,heap] Heap: 2048M(4096M)->1224M(4096M)   # 堆在 2 GB 与 4 GB 之间“蹦迪”

• -Xms2g -Xmx4g：JVM 被允许“按需增长”。
• 每次 Young GC 后，G1 发现 gc+ergo+heap 计算出的“最小堆” < 2 GB，于是把 已提交的 Eden/Survivor 全部归还给 OS。
• 下一秒流量进来，又立刻向 OS 申请 连续 512 MB 的虚拟地址，于是出现 RSS 抖动。

这就叫 JVM 级的空间震荡 —— 堆的动态收缩/扩张频率远高于业务流量变化频率，导致：

1. CPU 毛刺：提交/取消提交内存需要 madvise(MADV_DONTNEED)，系统调用开销 + TLB flush。
2. 延迟尖峰：Region 归还后再次申请，可能触发 整堆锁（Heap_lock）竞争。
3. 监控误报：Prometheus process_resident_memory_bytes 像心电图，告警规则瞬间爆炸。

溯源：JVM 到底什么时候“缩表”

结论：只要你用 -Xms < -Xmx，三大低延迟收集器都可能“好心办坏事”。

量化：一次收缩到底多大成本？

用 perf 跟踪一次 G1 Young GC → shrink → expand：

  3.25 ms : G1CollectedHeap::shrink_helper
  0.83 ms : os::pretouch_memory         # 重新提交时把整片内存写 0
  1.40 ms : os::commit_memory           # mmap(PROT_READ|PROT_WRITE)
  5.48 ms : os::tlb_flush_all          # 远程 CPU TLB shootdown

• 总耗时 ≈ 11 ms，几乎等价一次 Young GC STW。
• 在 4 vCPU 容器里，单次抖动就能让 P99 暴增至 20 ms+。

根治三板斧

1 禁止收缩：把 -Xms 设成 -Xmx

最直接、最暴力、最有效：

java -Xms4g -Xmx4g -XX:+UseG1GC ...

代价：启动即占用 4 GB RSS，容器 OOM 风险前移；但在 K8s 已设置 resources.limits.memory 的场景，反而是最可预测的方案。

2 延迟收缩：调大“空闲阈值”与“冷却窗口”

若业务确实有 昼夜峰谷，又不想一次性占满内存，可保留弹性，但拉长决策周期：

# G1：空闲 Region 超过堆 30 % 且持续 10 min 才归还
-XX:G1PeriodicGCInterval=600000
-XX:G1UncommitDelay=600000          # JDK 21+
-XX:G1ReservePercent=30             # 保守一点

# Shenandoah：空闲 > 10 % 且 5 min 后才 uncommit
-XX:+UnlockExperimentalVMOptions
-XX:ShenandoahUncommitDelay=300000

实测：

• 收缩频率从 每 30 s 降到 每 30 min；
• P99 延迟下降 40 %，云账单下降 12 %（夜间缩容收益）。

3 架构级：把“弹性”交给上层，而非 JVM

• K8s VPA（Vertical Pod Autoscaler） 只调 -Xms/-Xmx，滚动重启 Pod，避免运行时抖动。
• 分池部署：
  • 低峰池：-Xms1g -Xmx1g 固定；
  • 高峰池：-Xms4g -Xmx4g 固定；
  • 通过 Ingress 流量调度 切换，而非 JVM 内伸缩。

决策树：一分钟定位并选方案

JVM 抖动？
├─ RSS 锯齿 + GC 日志 shrink/expand → 空间震荡
│   ├─ 能否接受固定内存？ → -Xms = -Xmx
│   ├─ 需要弹性？ → 调大 UncommitDelay
│   └─ 需要分钟级弹性？ → 上层 VPA/分池
└─ 非内存抖动 → 排查 code cache/metaspace/direct memory

小结

动态堆 ≠ 弹性。 把伸缩决策从 JVM 内部移动到编排层，才能既享受云原生红利，又保住 P99。

下次有人问你：

“为啥 Young GC 后堆反而变小，下一秒又暴涨？”

你可以把这篇文章甩给他，并补一句：

“把 -Xms 设成 -Xmx，世界就安静了。”