K8s 中 Java 进程的 G1 与 ZGC 非堆内存开销深度对比：如何避免 Pod 被 OOM Killer 强杀

在 Kubernetes (K8s) 环境中部署 Java 应用时，很多架构师和运维工程师都遭遇过一个诡异的现象：JVM 堆内存（-Xmx）明明设置得离安全水位还有很大距离，但 Pod 依然因为 OOM (Exit Code 137) 被 K8s 强行杀掉。

这种现象的根源在于：JVM 进程占用的物理内存（RSS）远大于堆内存。 除了我们熟知的 Metaspace、Direct Memory、Thread Stack 之外，垃圾收集器（GC）自身的元数据和辅助数据结构，也是非堆内存（Non-Heap）开销中的大户。

本文将深度拆解 G1 与 ZGC 在非堆内存占用上的底层机制、硬性开销对比，并给出在 K8s 环境下如何精准估算内存 Limit 的实操建议。

一、 G1 收集器的非堆硬性开销

G1（Garbage-First）是一个基于 Region 的分代收集器。为了实现“可预测的停顿时间”，G1 引入了极其复杂的辅助数据结构，这些结构完全存储在 Native Memory（本地内存）中。

1. Remembered Sets (RSet) ── 最大的内存“小偷”

G1 将堆内存划分为数千个 Region。为了在进行 Minor GC（年轻代回收）时不用全堆扫描，G1 为每个 Region 配备了一个 RSet（记忆集）。

• 作用：记录“谁指向了我”（其他 Region 指向本 Region 的引用关系）。
• 开销机制：RSet 的底层是 Card Table（卡表）的稀疏/稠密多级哈希表结构。如果应用中的对象关联关系极其复杂（例如大对象频繁跨 Region 引用，或者高度耦合的微服务实体），RSet 的体积会急剧膨胀。
• 硬性开销：在生产环境中，G1 的 RSet 通常会吃掉堆大小的 5% ~ 15% 物理内存。如果堆大小为 16GB，RSet 可能会悄悄吃掉 1GB 到 2.4GB 的 Native Memory。

2. Collection Set (CSet) 与 Card Table

• CSet：记录单次 GC 中将要被回收的 Region 集合。虽然开销较小，但仍需占用几兆到几十兆的内存。
• Card Table：全局卡表，每 512 字节的堆内存对应卡表中的 1 字节（比例为 0.19%），这部分是静态硬性开销。

3. Marking Bitmaps（标记位图）

G1 的并发标记阶段使用两个位图（Prev Bitmap 和 Next Bitmap）来记录对象的存活状态。

• 硬性开销：每个位图中的 1 位（bit）对应堆中的一个对象对齐步长（默认 8 字节）。因此，一个位图大约占用堆内存的 $1 / (8 \times 8) = 1.56%$。两个位图加起来，硬性消耗堆大小的 ~3.1% 的物理内存。

二、 ZGC 收集器的非堆硬性开销

ZGC（Z Garbage Collector）是一款低延迟、基于 Region（在 ZGC 中称为 Page）、支持 TB 级堆的垃圾收集器。其无停顿的核心秘诀在于 Colored Pointers（染色指针） 和 Load Barriers（读屏障）。它的非堆内存开销模型与 G1 有着本质的区别。

1. 虚拟内存多重映射（Virtual Memory Multi-mapping）

在 JDK 21 之前（单代 ZGC），ZGC 使用了多重映射（Multi-mapping）技术。

• 机制：染色指针利用了 64 位虚拟地址中的几位来标记对象状态（Marked0, Marked1, Remapped）。为了让这三种状态的指针都能指向同一个物理内存地址，ZGC 在虚拟地址空间中创建了三个映射，指向同一片物理内存。
• 影响：这导致用 top 或 ps 命令查看时，JVM 进程的 VSIZE（虚拟内存）会膨胀到堆内存的 3 倍以上。虽然这不占用真正的物理内存（RSS），但在一些监控不完善、限制虚拟内存（ulimit -v）或 cgroup v1 审计严格的环境下，可能会触发报警或直接导致 JVM 启动失败。
• 注：自 JDK 21 引入分代 ZGC（Generational ZGC）后，默认不再使用多重映射，虚拟内存占用恢复正常。

2. ZPage 与 Page Table 元数据

• ZGC 的物理内存是以 Page 为单位分配的。为了管理这些 ZPage，ZGC 在 Native Memory 中维护了高精度的页表和并发标记栈。
• 硬性开销：由于 ZGC 没有 G1 那样复杂的 RSet（ZGC 依靠读屏障自愈和并发重定位，不需要在非堆中维护跨区引用），它的 GC 元数据开销极为稳定，通常仅占堆内存的 2% ~ 3% 左右。

3. 线程局部缓冲区（Thread Local Allocator）与 屏障开销

ZGC 的读屏障（Load Barrier）是由 JIT 编译器注入到 Java 代码中的。这些屏障的执行需要寄存器和少量的本地栈空间，间接增加了 Thread Stack（线程栈）的实际物理内存占用（RSS）。当线程数极多时，这部分非堆开销会有所上升。

三、 G1 vs ZGC 非堆硬性开销数据对比

假设在 K8s 中部署一个 堆大小 -Xmx16g -Xms16g 的 Java 服务，我们通过 JVM 的 NMT (Native Memory Tracking) 来量化两者的 GC 自身非堆硬性开销：

四、 为什么在 K8s 中 ZGC 比 G1 更不容易让 Pod 崩溃？

很多团队将垃圾收集器从 G1 切换到 ZGC 后，发现 Pod 运行得更加稳定，OOM 的频率显著降低。原因在于：

1. 非堆内存的“确定性”：
   G1 的 RSet 大小是不可控的。如果应用中出现了大范围的对象图谱交织，RSet 会在几分钟内暴涨上百兆，最终挤爆 K8s 的 Limit 限制。而 ZGC 抛弃了 RSet，它的 GC 元数据开销是线性的、可预测的。
2. 避免了 G1 的“晋升失败”引发的内存动荡：
   当 G1 发生 Full GC 时，为了加快处理速度，JVM 可能会向操作系统申请额外的临时 native 内存。而在 K8s 的严格限制下，这种突发性的 native 内存申请是致命的。

五、 K8s Pod 内存容量规划公式

要在 K8s 中给 Java Pod 设置合理的 resources.limits.memory，请不要直接套用“堆内存 + 1GB”这种玄学公式。

我们可以采用以下更为精确的推导公式：

$$\text{K8s Memory Limit} = \text{Heap} (-Xmx) + \text{Metaspace} + \text{DirectMemory} + (\text{ThreadNum} \times \text{StackSize}) + \text{GC Metadata} + \text{Safety Buffer}$$

1. 核心参数推荐配置：

• Thread Stack：默认为 1MB（-Xss1m）。若有 500 个线程，则需预留 500MB。
• Metaspace：通常配置 -XX:MaxMetaspaceSize=256m 或 512m。
• Direct Memory：若使用了 Netty/Spring WebFlux，默认最大可达 -Xmx 的大小。必须显式限制，如 -XX:MaxDirectMemorySize=512m。

2. GC 专有预留（GC Metadata）：

• G1 收集器：预留 -Xmx 的 $10% \sim 15%$。
• ZGC 收集器：预留 -Xmx 的 $3% \sim 5%$。

3. Safety Buffer（安全余量）：

用于应对 glibc 的内存碎片、JVM 自身运行、以及 Pod 内可能存在的其他辅助进程（如 APM Agent、Filebeat 等）。通常保留 256MB ~ 512MB。

实战演练：以 8GB 堆为例

假设 -Xmx8g，线程数 300，Metaspace 限制 256MB，DirectMemory 限制 512MB：

• 使用 G1 收集器：
  $$8\text{GB (Heap)} + 256\text{MB (Metaspace)} + 512\text{MB (Direct)} + 300\text{MB (Threads)} + \mathbf{1\text{GB (G1 Metadata, ~12%)}} + 300\text{MB (Buffer)} \approx \mathbf{10.36\text{GB}}$$
  建议 K8s Limit 设定为 10.5Gi 或 11Gi。

• 使用 ZGC 收集器 (JDK 21+)：
  $$8\text{GB (Heap)} + 256\text{MB (Metaspace)} + 512\text{MB (Direct)} + 300\text{MB (Threads)} + \mathbf{320\text{MB (ZGC Metadata, ~4%)}} + 300\text{MB (Buffer)} \approx \mathbf{9.68\text{GB}}$$
  建议 K8s Limit 设定为 10Gi。

总结

在 K8s 的精细化运维时代，ZGC 不仅带来了极致的低延迟，还带来了比 G1 更加稳定、可预测的非堆内存占用。

如果你的 Java 应用运行在 K8s 中，且频繁因为非堆内存飘忽不定而被 OOM 强杀，不妨尝试：

1. 开启 NMT (-XX:NativeMemoryTracking=summary)，在测试环境用 jcmd <pid> VM.native_memory baseline 监控真实的非堆分布。
2. 升级到 JDK 17/21，将垃圾收集器切换至 ZGC，不仅能拯救你的响应时间，更能挽救你的 Pod 存活率。