G1垃圾收集器原理与调优：Region化内存管理与可控停顿实践

1. G1 垃圾收集器不是“更快的CMS”，而是为可控停顿而生的内存管理范式

G1 垃圾收集器，全称 Garbage-First，是 Java HotSpot VM 自 JDK 7u4 起正式商用、JDK 9 成为默认 GC 的核心组件。它不是简单地把 CMS 换个名字再提速，而是一次对 JVM 内存管理底层逻辑的重构——目标非常明确：在堆内存达到数 GB 甚至数十 GB 规模时，依然能将单次 GC 停顿（Stop-The-World）稳定控制在 200ms 以内，且不以牺牲吞吐量为代价。这背后，是它彻底抛弃了传统分代收集器“年轻代/老年代”物理隔离的刚性结构，转而采用基于区域（Region）的堆内存划分 + 可预测停顿模型 + 并发标记与增量整理三位一体的设计哲学。

你在网上搜到的“g1 主观赋权法”其实是个误传，没有这个官方术语；真正起作用的是 G1 的动态优先级排序机制——它会实时估算每个 Region 的回收价值（即“垃圾比例 × 回收耗时预期”），并按价值从高到低排列，每次 GC 只选最“划算”的若干 Region 进行回收，这就是“Garbage-First”名称的由来。而“gc(g1 old,all)是什么意思”这类问题，本质是对 G1 回收范围的误解：G1 不再有严格意义上的“Old GC”，它只有一种统一的 Mixed GC 模式，当老年代 Region 被标记为可回收后，就会和部分年轻代 Region 一起打包进下一轮 Mixed GC，不存在单独触发“老年代全回收”的指令。至于“com.android.systemui heaptaskdaemon 影响gc”，这是 Android 系统层面对 G1 行为的定制化干预，普通 Java 应用无需关注，但提醒我们：G1 的行为高度依赖 JVM 参数与运行时负载特征，不是配完-XX:+UseG1GC就万事大吉。

如果你正被 JVM 面试题反复拷问“G1 和 CMS 有什么区别”，或者在生产环境里因 GC 停顿抖动导致接口超时、订单丢失，又或者在调优时发现-Xmx32g的服务，Young GC 还算稳，但一触发 Mixed GC 就卡顿 800ms——那说明你还没真正看懂 G1 的心跳节律。它不像 Serial 那样简单粗暴，也不像 ZGC 那样追求极致低延迟，G1 是工程师思维的产物：用可量化的停顿目标倒逼整个回收流程的精细化调度。接下来，我们就一层层剥开它的内核，不讲教科书定义，只说它在真实服务器上怎么呼吸、怎么决策、怎么避免把你拖进凌晨三点的告警漩涡。

2. G1 的整体设计思路：用“区域化”打破分代枷锁，用“预测模型”驯服不确定性

2.1 为什么必须放弃传统的“连续堆+固定代际”结构？

先看一个典型痛点：某电商订单服务，堆内存设为-Xmx16g，使用 Parallel GC。高峰期 Young GC 每 2 秒一次，每次 30ms，没问题；但一旦促销开始，大量订单对象晋升到老年代，老年代占用率从 30% 快速爬升至 85%，触发 Full GC。Parallel Old GC 开始扫描整个 12GB 老年代空间，单次停顿长达 1.2 秒——用户下单按钮点击后 1.2 秒无响应，支付超时率飙升。根本原因在于：传统分代收集器的老年代是一整块连续内存，GC 时必须遍历所有存活对象做标记，对象越多、碎片越重，扫描时间越不可控。

G1 的破局点，就是把这块“不可控的大蛋糕”切成无数块“可控的小切片”。它将整个 Java 堆（无论大小）划分为多个大小相等的Region，每个 Region 通常是 1MB～4MB（由 JVM 根据堆总大小自动计算，例如 4GB 堆默认 2MB/Region）。关键在于：这些 Region物理上连续，逻辑上完全独立。一个 Region 可以充当 Eden，另一个可以是 Survivor，第三个可以是 Old，第四个甚至可以是 Humongous（存放超大对象，如 1MB 以上的 byte[]）。这种设计带来三个质变：

1. 回收粒度从“代”降维到“Region”：不再需要扫描整个老年代，只需评估哪些 Region 垃圾最多、回收收益最高，精准打击。
2. 空间分配从“连续寻址”变为“自由拼接”：Eden 区不再需要一大片连续内存，JVM 只需从空闲 Region 列表中挑几个出来即可，极大缓解内存碎片压力。
3. 停顿时间从“看天吃饭”变为“可配置目标”：G1 的核心参数-XX:MaxGCPauseMillis=200不是承诺值，而是调度目标。它会根据历史 GC 数据（如各 Region 回收耗时、对象晋升速率），动态调整每次 Mixed GC 所选 Region 的数量和类型，确保平均停顿逼近该目标。

提示：G1 的 Region 大小在 JVM 启动时就固定，无法运行时调整。若应用大量创建 1.5MB 的缓存对象，而 Region 设为 1MB，则每个对象独占 2 个 Region，造成严重浪费。此时应通过-XX:G1HeapRegionSize=2M手动指定 Region 大小，让大对象能恰好填满一个 Region。

2.2 G1 的三大核心阶段：如何实现“并发标记”与“增量整理”的协同？

G1 的完整 GC 周期分为四个阶段，但真正影响应用线程的是其中两个 STW（Stop-The-World）环节，其余均为并发执行：

• 初始标记（Initial Mark）：STW，极短（通常 < 5ms）。仅标记从 GC Roots 直接可达的对象（如线程栈、静态变量），并标记这些对象所在 Region 为“存活”。这步快是因为它不遍历对象图，只做根节点快照。

• 并发标记（Concurrent Marking）：完全并发，应用线程与 GC 线程并行。G1 的标记线程会遍历 Initial Mark 标记出的存活对象，逐层向下扫描其引用链，同时记录每个 Region 的存活对象总数与垃圾占比。此阶段会产生“三色标记”中的“灰色”（已标记但未扫描子对象）和“黑色”（已完全扫描）对象。关键创新在于“SATB（Snapshot-At-The-Beginning）写屏障”：当应用线程修改对象引用（如obj.field = newObject）时，写屏障会将被覆盖的旧引用（oldValue）记录到一个缓冲区（SATB Buffer），供后续并发标记线程检查——这保证了即使标记过程中对象图发生变更，也不会漏标。

• 最终标记（Remark）：STW，中等时长（通常 20～50ms）。处理 SATB Buffer 中的残留记录，并完成标记的精确修正。这是 G1 唯一需要全局暂停来“收尾”的环节。

• 清理与复制（Cleanup & Evacuation）：分为并发清理（Concurrent Cleanup）和混合回收（Mixed GC）两部分。前者并发统计各 Region 的垃圾占比；后者才是真正的“干活”阶段：G1 选出一批高价值 Region（主要是垃圾多的老年代 Region，附带少量年轻代 Region），在 STW 下将其中存活对象复制到新的空闲 Region 中，同时整理内存、消除碎片。这才是 G1 实现“标记-整理”而非“标记-清除”的关键——它不直接在原 Region 上覆写，而是搬迁，天然压缩空间。

注意：G1 的“整理”是增量式、选择性的。它不会一次性整理整个老年代，而是每次 Mixed GC 只整理一部分 Region。这正是它能兼顾低延迟与高吞吐的秘诀：用多次小停顿，替代一次大停顿。

2.3 G1 的“主观赋权”真相：回收价值模型如何动态计算？

网络热词“g1 主观赋权法”纯属误读，G1 的决策依据是客观、可计算的回收价值模型。其核心公式为：

RegionValue = (RegionTotalBytes - RegionLiveBytes) / RegionEvacuationTimeMs

• RegionTotalBytes：Region 总大小（如 2MB）
• RegionLiveBytes：并发标记阶段估算出的该 Region 存活对象字节数
• RegionEvacuationTimeMs：G1 根据历史数据预测的，将该 Region 存活对象复制到新 Region 所需的时间（考虑对象大小、跨 Region 引用复杂度等）

G1 维护一个按RegionValue降序排列的 Region 列表。每次 Mixed GC 开始前，它会：

1. 查询当前堆内存使用率、老年代占用率、历史 GC 停顿时间；
2. 根据-XX:MaxGCPauseMillis目标，反推本次允许的最大 evacuation 时间；
3. 从列表顶端开始累加 Region 的RegionEvacuationTimeMs，直到总和逼近目标时间；
4. 将这些高价值 Region 打包，发起本轮 Mixed GC。

这意味着：一个刚被大量对象填满、但其中 90% 是垃圾的 Region，价值极高；而一个只有 10% 垃圾、但对象引用关系极其复杂的 Region，价值可能很低，会被延后处理。这种动态调度，让 G1 在面对不同业务负载（如 OLTP 短事务 vs OLAP 长计算）时，都能找到最优回收路径。

3. G1 的核心细节解析：参数、日志、内存布局与实操陷阱

3.1 关键参数详解：不是堆越大越好，而是“配得越准，停顿越稳”

G1 的参数体系远比 Parallel GC 复杂，但核心就五个，配错一个，效果天壤之别：

• -XX:+UseG1GC：启用 G1，这是前提，但绝非终点。

• -XX:MaxGCPauseMillis=200：最常被滥用也最易被误解的参数。它不是 SLA，而是 G1 的“努力方向”。如果设为 50ms，而你的机器 IO 或 CPU 已饱和，G1 会强行减少每次回收的 Region 数量，导致老年代持续增长，最终触发 Full GC（此时停顿可能达数秒）。实测经验：生产环境建议设为 200～300ms，给 G1 留出合理调度空间。

• -XX:G1HeapRegionSize=2M：Region 大小。默认由 JVM 计算（堆大小 / 2048），但必须手动校准。判断依据：查看 GC 日志中Humongous Allocation的频率。若频繁出现，说明 Region 太小，大对象被迫拆分或直接进入 Humongous 区，加剧碎片。此时应增大此值，原则是：RegionSize >= 1.5 × 应用最大常规对象大小。

• -XX:G1NewSizePercent=20与-XX:G1MaxNewSizePercent=40：年轻代占堆比例的上下限。G1 不固定年轻代大小，而是动态伸缩。设为 20/40，意味着年轻代可在 3.2GB～6.4GB（16GB 堆）间浮动。关键技巧：若 Young GC 频繁（< 1s 一次），说明下限设太低，应提高G1NewSizePercent；若 Mixed GC 过于激进（每 2 分钟一次），说明上限太高，年轻代吃掉太多空间，应降低G1MaxNewSizePercent。

• -XX:G1MixedGCCountTarget=8与-XX:G1MixedGCLiveThresholdPercent=85：控制 Mixed GC 的节奏。前者表示 G1 希望用 8 次 Mixed GC 清完所有可回收的老年代 Region；后者表示只有当 Region 存活对象 ≤ 15% 时，才将其纳入 Mixed GC。避坑点：不要盲目调低G1MixedGCLiveThresholdPercent（如设为 50）！这会导致大量“半满”Region 被过早回收，复制成本飙升，反而拉长停顿。

实操心得：我曾在一个实时风控服务上，将MaxGCPauseMillis从 100ms 强行压到 50ms，结果 GC 日志显示G1 Evacuation Pauses平均停顿确实降到 48ms，但Full GC每小时发生 3 次。回滚后设为 250ms，Full GC 彻底消失，平均停顿 210ms，业务成功率反而提升 0.3%。G1 的智慧，在于接受“可控的延迟”，而非追求“绝对的低延迟”。

3.2 GC 日志解码：读懂 G1 的“体检报告”，比调参更重要

开启详细 GC 日志：-Xlog:gc*,gc+heap*,gc+ergo*,gc+age=debug:file=/path/to/gc.log:time,tags,level（JDK 10+）。关键字段解读：

• [GC pause (G1 Evacuation Pause) (young)：纯 Young GC，只回收年轻代 Region。
• [GC pause (G1 Evacuation Pause) (mixed)：Mixed GC，回收年轻代 + 部分老年代 Region。
• [GC pause (G1 Evacuation Pause) (full)：灾难性的 Full GC，G1 回退到 Serial GC，必须杜绝。
• Eden: 1234M(1234M)->0B(1234M)：Eden 区使用量变化，括号内为容量。
• Survivor: 123M->245M：Survivor 区对象晋升量，若持续增长，说明对象寿命变长，可能需调大 SurvivorRatio。
• Heap: 8192M->3245M(16384M)：堆内存变化，8192M是 GC 前已用，3245M是 GC 后已用，16384M是总容量。
• Metaspace: 123456K->123456K(1126400K)：元空间变化，若used持续上涨，可能是类加载泄漏。
• evacuation failed：复制失败！意味着目标 Region 空间不足或跨 Region 引用过于复杂。这是 Mixed GC 停顿飙升的前兆，需立即检查G1HeapRegionSize和G1MaxNewSizePercent。

一份健康 G1 日志的特征：

• Young GC 频率稳定（如每 1～3 秒一次），停顿 < 50ms；
• Mixed GC 间隔合理（如每 5～15 分钟一次），停顿在MaxGCPauseMillis± 20% 范围内；
• evacuation failed字样零出现；
• Full GC行数为 0。

3.3 G1 内存布局实战：Region 的七种角色与 Humongous 对象的隐形杀手

G1 堆内存由数千个 Region 构成，每个 Region 根据当前状态扮演不同角色：

Region 类型	特征	占比	关键影响
Eden	新对象分配区，GC 后清空	动态，通常 30%～50%	Young GC 频率直接由 Eden 大小决定
Survivor	存放 Young GC 中幸存的对象，经历多次 GC 后晋升	通常 5%～10%	SurvivorRatio参数影响其大小，过小导致过早晋升
Old	存放晋升对象，是 Mixed GC 的主要回收目标	初始为 0，随晋升增长	老年代占用率 > 45% 是 Mixed GC 触发阈值
Humongous	存放 ≥ ½ RegionSize 的超大对象（如大数组、缓存块）	可能 1%～20%	最大陷阱！Humongous Region 不参与常规 GC，只能等整个 Region 变成垃圾才回收，极易导致内存浪费与 Full GC
Free	空闲 Region，等待分配	动态	若长期低于 10%，说明堆压力过大
Archive	JDK 10+ 引入，存放不可变类数据（如 bootstrap classes）	固定，很小	与业务无关，可忽略
Unused	已分配但未使用的 Region	0	正常

Humongous 对象的识别与治理：在 GC 日志中搜索humongous allocation。若发现Allocated 123456 bytes as humongous for ...，说明有对象超过G1HeapRegionSize/2。解决方案：

1. 代码层：拆分大对象，如将 10MB 缓存数组改为 10 个 1MB 的 List；
2. JVM 层：增大-XX:G1HeapRegionSize，让大对象能恰好填满一个 Region；
3. 架构层：将超大对象移出堆内存，改用 off-heap（如 Netty 的 PooledByteBufAllocator）或磁盘存储。

实操案例：某推荐系统日志模块，因打印完整 JSON 请求体，产生大量 512KB 的 String 对象。RegionSize 默认 1MB，512KB < 500KB（1MB/2），本不该是 Humongous。但 String 内部 char[] 在 JDK 8 中是 UTF-16 编码，512KB String 对应 256KB char[]，仍安全。问题出在 JDK 11+ 的 Compact Strings 优化：String 底层可能用 byte[] 存储 Latin-1 字符，此时 512KB String 可能对应 512KB byte[]，刚好踩在 1MB Region 的 50% 边界上，被判定为 Humongous。最终方案：升级 JDK 后，将G1HeapRegionSize设为 4M，彻底规避。

3.4 G1 与 JVM 内存模型的深度耦合：为什么 Metaspace 和 CodeCache 也会影响 GC？

很多人以为 G1 只管堆内存，这是巨大误区。JVM 内存模型中，Metaspace（元空间）和 CodeCache（代码缓存）的异常，会直接诱发 G1 的 Full GC。

• Metaspace 泄漏：动态生成类（如 Spring CGLIB、MyBatis Mapper）过多，或 ClassLoader 未正确释放，导致 Metaspace 持续增长。当 Metaspace 达到-XX:MaxMetaspaceSize限制时，JVM 会触发 Full GC 来尝试卸载无用类。对策：监控jstat -gc <pid>中MU（Metaspace Used）列，若持续上涨，用jmap -histo:live <pid>查看类加载器分布。

• CodeCache 溢出：JIT 编译的热点代码过多，填满 CodeCache（默认 240MB）。此时 JVM 会停止 JIT 编译，并可能触发 Full GC。对策：-XX:ReservedCodeCacheSize=512m适当增大，或-XX:-TieredStopAtLevel=1关闭 C2 编译器（牺牲性能换稳定）。

• Direct Memory 泄漏：ByteBuffer.allocateDirect()分配的堆外内存，虽不属堆，但其 Cleaner 对象在堆内。若 Direct Memory 泄漏，Cleaner 队列积压，会拖慢 G1 的并发标记阶段，间接拉长 Mixed GC 停顿。对策：-XX:MaxDirectMemorySize=2g严格限制，并用jcmd <pid> VM.native_memory summary监控。

注意：jvm gc回收器、jvm调优工具如 jstat、jmap、VisualVM，它们看到的只是堆内存视图。要全面诊断 G1 问题，必须结合jstat -gc <pid>（看 Metaspace）、jstat -compiler <pid>（看 CodeCache）、jcmd <pid> VM.native_memory（看 Direct Memory），形成四维监控矩阵。

4. G1 的实操过程：从零部署、参数调优到线上故障排查全流程

4.1 新服务上线：G1 的最小可行配置与基线测试

不要一上来就堆砌 20 个参数。新服务部署 G1，遵循“三步走”：

第一步：基础启用与基线采集

# JVM 启动参数（JDK 8u261+ 或 JDK 11+） -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -Xms8g -Xmx8g \ -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \ -Xloggc:/opt/app/logs/gc.log

运行 24 小时，用jstat -gc <pid> 5000（每 5 秒采样）记录：

• Young GC 频率与平均停顿
• Mixed GC 频率与平均停顿
• 堆内存使用率趋势（重点关注老年代占用率是否缓慢爬升）

第二步：Region 大小校准分析 GC 日志，搜索humongous allocation。若存在，计算最大 Humongous 对象大小：

grep "humongous" gc.log | awk '{print $8}' | sort -n | tail -1 # 输出类似：1234567 -> 约 1.2MB

则设置-XX:G1HeapRegionSize=2M（取略大于 1.2MB 的 2 的幂次方），重启服务，再观察 12 小时。

第三步：年轻代弹性调优若 Young GC 过于频繁（< 1s 一次），说明 Eden 太小：

# 先临时加大年轻代下限 -XX:G1NewSizePercent=30

若 Mixed GC 过于密集（< 5 分钟一次），说明年轻代吃掉太多空间，老年代“饿”得快：

# 临时收紧年轻代上限 -XX:G1MaxNewSizePercent=35

每次调整后，至少观察 4 小时，对比jstat数据变化。

实操心得：我给一个新上线的物流轨迹服务配 G1，初始-Xmx4g，MaxGCPauseMillis=200。基线测试发现 Young GC 每 800ms 一次，停顿 25ms；Mixed GC 每 18 分钟一次，停顿 180ms。一切健康。但上线第三天，监控显示老年代占用率从 20% 突然跳到 65%，Mixed GC 频率飙升至每 2 分钟一次。查日志发现humongous allocation频繁。原来轨迹点数据序列化后，单条消息达 1.8MB。将G1HeapRegionSize改为 4M 后，问题消失。G1 调优的第一敏感点，永远是 Humongous 对象，而不是停顿目标。

4.2 生产环境深度调优：应对流量洪峰与内存泄漏的组合拳

生产环境 G1 调优，核心是“预判 + 监控 + 快速干预”。

预判：为大促准备 GC 安全垫

• 提前一周，用压测工具模拟 3 倍峰值流量，观察 GC 行为；
• 若 Mixed GC 停顿逼近MaxGCPauseMillis的 90%，则：
  • 将-XX:MaxGCPauseMillis临时上调至 300ms（给 G1 更宽松的调度空间）；
  • 增加-XX:G1ReservePercent=20（预留 20% 堆空间作为“安全气囊”，防止 Mixed GC 期间无空闲 Region 可用）；
  • 设置-XX:G1HeapWastePercent=5（允许最多 5% 的堆空间被标记为“浪费”，避免为清理最后一点垃圾而触发 Full GC）。

监控：构建 G1 健康度仪表盘关键指标（全部可通过 JMX 或 Prometheus Exporter 采集）：

• G1YoungGenerationCount：Young GC 次数/分钟，> 60 次/分钟需预警；
• G1MixedGenerationCount：Mixed GC 次数/分钟，> 5 次/分钟需预警；
• G1OldGenerationSize：老年代已用内存，> 堆总大小的 70% 需预警；
• G1HumongousObjects：Humongous 对象数量，持续增长需排查；
• G1EvacuationInfo：各 Region 的回收效率，EvacuationFailureRate> 0.1% 即危险。

快速干预：三板斧止血当线上出现 GC 告警（如 Mixed GC 停顿 > 500ms）：

1. 第一反应：jstat -gc <pid> 1000 5连续采样 5 次，确认是否偶发还是持续；
2. 第二反应：若确认恶化，立即执行jcmd <pid> VM.native_memory summary scale=MB，检查 Direct Memory 是否暴涨；
3. 第三反应：若 Direct Memory 正常，执行jmap -histo:live <pid> | head -20，看是否有异常类实例暴增（如java.util.HashMap实例数翻倍），指向内存泄漏。

实操案例：某支付网关在双十一流量高峰，Mixed GC 停顿从 200ms 暴涨至 1200ms。jstat显示G1OldGenerationSize在 10 分钟内从 4GB 涨到 7GB。jmap -histo发现com.alipay.xxx.PaymentContext实例数达 200 万。排查代码，发现 Context 对象被静态 Map 缓存，且未设置过期策略。紧急上线修复，同时将G1ReservePercent从 10% 提至 20%，为修复窗口争取时间。G1 不是万能的，它是放大镜，会把代码里的内存问题，以更尖锐的停顿形式暴露出来。

4.3 G1 常见故障排查：从日志到火焰图的全链路诊断

故障一：Mixed GC 停顿时间忽高忽低，波动剧烈

现象：GC 日志中G1 Evacuation Pause (mixed)停顿时间在 100ms～800ms 间随机跳跃，无明显规律。

排查路径：

1. jstat -gc <pid> 1000 10：确认是否伴随G1OldGenerationSize快速上升；
2. jstack <pid> | grep "RUNNABLE" -A 5：检查是否有线程在执行耗时 IO（如慢 SQL、外部 HTTP 调用），导致 GC 线程被抢占；
3. top -H -p <pid>：看 GC 线程（G1 Conc#0等）CPU 使用率是否被其他线程压制；
4. 终极手段：用async-profiler生成 GC 期间的 CPU 火焰图：

   ./profiler.sh -e cpu -d 30 -f /tmp/gc-flame.svg <pid>

   若火焰图显示大量时间在Unsafe_GetObject或ObjectSynchronizer::inflate，说明存在严重锁竞争，GC 线程无法获得足够 CPU 时间片。

根因与解决：G1 的 Mixed GC 是 STW，但其并发标记阶段依赖 CPU 资源。若应用线程 CPU 占用率长期 > 90%，GC 线程得不到调度，导致标记延迟，最终在 STW 阶段需要处理更多待回收对象，停顿飙升。对策：限流降级非核心接口，或增加机器 CPU 核数。

故障二：频繁evacuation failed，随后触发 Full GC

现象：GC 日志中连续出现evacuation failed，紧接着Full GC。

根因分析：

• G1HeapRegionSize过小，导致大量 Humongous Region，挤占空闲 Region；
• G1MaxNewSizePercent过高，年轻代疯狂扩张，留给老年代回收的空闲 Region 不足；
• 应用存在大量跨 Region 引用（如一个大对象持有数百个散落在不同 Region 的小对象引用），导致复制时目标 Region 空间不足。

解决步骤：

1. 立即检查G1HeapRegionSize，若存在 Humongous，按前述方法增大；
2. 降低G1MaxNewSizePercent至 30%，释放更多 Region 给老年代回收；
3. 用jmap -dump:format=b,file=/tmp/heap.hprof <pid>生成堆转储，用 Eclipse MAT 分析Retained Heap最大的对象，看其引用链是否异常复杂。

注意：evacuation failed是 G1 的“求救信号”，不是错误。它意味着 G1 认为当前配置下无法安全完成回收，主动放弃本次 Mixed GC，等待下次。但若连续发生，就会退化为 Full GC。预防胜于治疗，日常监控G1EvacuationFailureRate是 SRE 的必修课。

故障三：G1 Old Generation占用率持续缓慢上升，Mixed GC 无法有效回收

现象：G1OldGenerationSize每小时上涨 1%，Mixed GC 后仅下降 0.2%，老年代“只进不出”。

根因锁定：

• 内存泄漏：对象被静态集合、ThreadLocal、缓存等意外持有；
• 对象晋升阈值过低：-XX:MaxTenuringThreshold=1导致对象 1 次 Young GC 就晋升；
• G1 的并发标记滞后：应用分配速度远超 G1 标记速度，导致大量老年代 Region 未被及时标记为可回收。

验证与解决：

• 执行jmap -histo:live <pid> | head -20，对比两次结果，看哪些类实例数持续增长；
• 检查jstat -gc <pid>中G1MixedGenerationCount是否为 0，若是，说明 G1 认为老年代还不“饿”，需调低-XX:G1MixedGCLiveThresholdPercent（谨慎！）；
• 最有效手段：强制触发一次并发标记周期jcmd <pid> VM.g1_run_final_mark，然后观察 Mixed GC 是否恢复。

5. G1 的边界与未来：何时该放弃 G1，拥抱 ZGC 或 Shenandoah？

G1 是成熟、稳健、适用面最广的 GC，但它不是银弹。在以下场景，G1 的“可控停顿”优势会迅速瓦解，必须考虑替代方案：

5.1 G1 的硬伤：大堆下的“标记-整理”成本天花板

G1 的 Mixed GC 停顿时间，与本次回收的 Region 数量 × Region 平均存活对象大小呈线性关系。当堆达到 64GB，且业务对象普遍较大（如金融风控中的复杂实体），一次 Mixed GC 需搬运数 GB 存活对象，即使只回收 10 个 Region，停顿也可能突破 500ms。此时，ZGC 的“着色指针 + 读屏障”架构，能将停顿稳定在 10ms 内，代价是 15% 的吞吐量损失和更高的内存占用（约 16%）。

决策树：

• 堆 ≤ 16GB，停顿要求 < 200ms → G1 是首选；
• 堆 16～64GB，停顿要求 < 10ms，且能接受吞吐量下降 → ZGC；
• 堆 > 64GB，或需要亚毫秒级停顿（如高频交易）→ ZGC 或 Shenandoah。

5.2 G1 与 JVM 生态的协同演进：从 JDK 8 到 JDK 21 的关键变迁

• JDK 8u202+：G1 稳定，但G1ReservePercent默认 10%，在大堆下易触发 Full GC；
• JDK 9：G1 成为默认 GC，引入G1UseAdaptiveIHOP（自适应初始堆占用预测），减少早期 Mixed GC；
• JDK 10：G1NewSizePercent/G1MaxNewSizePercent默认值优化，年轻代弹性更好；
• JDK 11：ZGC 发布（实验性），G1 开始面临挑战；
• JDK 17：ZGC 生产就绪，G1 的“默认地位”被撼动；
• JDK 21：虚拟线程（Project Loom）普及，大量短生命周期虚拟线程对象，G1 的 Young GC 效率优势凸显，但对老年代压力增大。

个人体会：我在 2023 年将一套 JDK 8 的风控系统升级到 JDK 17，保留 G1。最大的收益不是停顿降低，而是jstat中G1YoungGenerationCount下降了 40%——虚拟线程让对象生命周期更短，大部分在 Eden 就被回收，老年代压力骤减。G