1. 从一次线上告警说起：为什么我们需要深入了解G1 GC？

那天凌晨，手机突然响起刺耳的告警声。线上一个核心服务的响应时间曲线像坐了火箭一样直线飙升，从平时的50毫秒瞬间突破了5秒。登录服务器一看，CPU使用率并不高，但内存使用率却居高不下，Full GC的日志像瀑布一样刷屏，每次停顿都接近10秒。业务几乎陷入停滞。经过一番紧急排查，根源指向了JVM垃圾回收器——我们当时使用的是CMS，但在堆内存达到32GB、且对象分配速率极高的场景下，它已经力不从心，出现了“并发模式失败”，最终导致了那次严重的服务雪崩。

这次事故让我下定决心，必须彻底搞懂一个更适应现代大内存、多核处理器应用的垃圾回收器：G1（Garbage-First）。它从JDK 9开始成为默认的垃圾回收器，取代了Parallel Scavenge和CMS。但很多开发者对它的认知可能还停留在“默认的、更先进的回收器”这个层面，对于其内部原理、关键参数如何调优，依然雾里看花。结果就是，要么沿用默认参数“躺平”，遇到性能问题束手无策；要么胡乱调整几个-XX参数，效果可能适得其反。

这篇文章，我想从一个一线开发/运维的视角，拆解G1 GC的核心工作机制。我不会只讲教科书上的概念，而是结合我多次在真实生产环境中调试、踩坑、最终稳定服务的经验，告诉你G1到底是怎么工作的，它的那些关键参数（比如-XX:MaxGCPauseMillis、-XX:G1HeapRegionSize）背后真正的含义是什么，以及在不同场景（高吞吐批处理、低延迟在线服务、大内存应用）下，我们应该如何有的放矢地进行设置和调优。目标很明确：让你不仅能看懂G1的日志，更能真正驾驭它，让你负责的服务跑得更稳、更快。

2. G1 GC的核心设计思想：化整为零与可预测的停顿

在G1出现之前，主要的垃圾回收器（如Serial， Parallel， CMS）都采用分代收集，并且堆内存的布局是连续的，分为年轻代（Young Generation）和老年代（Old Generation）。这种布局在堆很大时（比如几十GB），进行一次全局的垃圾回收（尤其是Full GC），停顿时间会非常长，且不可预测。

G1采用了一种革命性的设计思路：将连续的Java堆划分为多个大小相等、物理上不连续的独立区域（Region）。每个Region可以是Eden区、Survivor区或Old区，但它们的角色在运行期可以动态变化。这种设计的精妙之处在于，G1不再坚持一次收集整个年轻代或整个老年代，而是优先去回收那些垃圾最多（Garbage-First名字的由来）、回收收益最高的Region集合。通过每次只处理一部分Region，将原本一次漫长的GC停顿，分散到多次短暂的、可控的停顿中，从而实现了可预测的停顿时间模型。

2.1 Region：堆内存管理的基本单元

Region的大小可以通过-XX:G1HeapRegionSize指定，范围从1M到32M，且必须是2的幂。JVM会基于堆的初始大小和最大大小自动计算一个合理的值（通常是堆大小的1/2000左右）。例如，你设置了-Xmx16g，JVM可能会选择Region大小为8MB（16GB / 2000 ≈ 8MB）。

注意：Region大小设置需要权衡。Region太小，会导致Region数量过多，增加管理开销；Region太大，可能导致大对象分配问题（后面会讲）。通常不建议手动设置，除非有明确需求（比如为了适配特定的大对象）。

每个Region都通过一个Remembered Set（RSet）来记录来自其他Region的引用。这是G1实现并发的关键。因为G1在做部分Region收集（即Mixed GC）时，需要知道哪些外部对象引用了当前Region内的存活对象，以避免扫描整个堆。RSet就像一个“外来人口登记簿”，极大地缩小了扫描范围。

2.2 G1的运作阶段：不是简单的Young/Old GC

G1的收集活动不像CMS那样清晰地分为Young GC和Old GC。它主要有三种收集类型：

1. Young GC：当Eden区被填满时触发。这时G1会暂停所有应用线程（Stop-The-World），将Eden区和Survivor区（From）的存活对象拷贝到新的Survivor区（To）或晋升到Old区的Region中。这个过程是并行多线程的，旨在高效利用多核CPU。

2. Mixed GC：这是G1实现“可预测停顿”的核心。当堆内存使用率达到一定阈值（默认45%，由-XX:InitiatingHeapOccupancyPercent控制）时，G1会启动一个并发标记周期。这个周期结束后，G1就知道了哪些Region的垃圾比例高。随后的Mixed GC就会在回收所有年轻代Region（Eden+Survivor）的同时，选择性地回收一部分被标记为“高垃圾比例”的老年代Region。Mixed GC也是STW的，但通过控制回收的Region数量，可以努力达到我们设定的停顿时间目标。

3. Full GC：这是我们要极力避免的。当G1在进行并发标记时，如果对象分配速度太快，导致在Mixed GC还没来得及回收足够空间时，堆就被填满了，这时就会触发一次单线程的、STW的Full GC，性能灾难就此发生。调优的核心目标之一就是避免Full GC。

3. 关键参数详解与调优实战

理解了核心思想，我们来看那些让人眼花缭乱的JVM参数。我不打算罗列所有参数，只聚焦那些对性能有决定性影响的关键开关。

3.1 停顿时间目标：-XX:MaxGCPauseMillis

这是G1调优的“指挥棒”，默认值是200毫秒。它告诉G1：“我希望每次GC停顿的时间尽量不超过这个值。”

重要理解：这个参数是一个目标，而非硬性保证。G1会努力通过调整每次回收的Region数量（主要是年轻代的大小）来逼近这个目标。如果你设了一个不切实际的目标（比如20ms），G1可能会将年轻代设置得非常小，导致GC频率急剧升高，虽然每次停顿短了，但总体吞吐量会严重下降。

调优建议：

• 不要盲目设小：对于大多数延迟不敏感的后台服务或批处理任务，200ms或甚至300ms都是可以接受的，这样可以换取更高的吞吐量。
• 如何确定合理值：监控系统现有的GC日志，观察“正常”情况下Young GC和Mixed GC的实际停顿时间（[Eden: ...->... Survivors: ...->... Heap: ...]后面的时间）。以此为基准，设置一个略高于平均值的MaxGCPauseMillis，给G1一些缓冲空间。例如，观测到Young GC平均停顿80ms，可以设置为100-150ms。
• 配合监控：设置后，必须持续监控G1 Young Generation的G1 Eden Space的容量变化，以及GC频率。如果发现Eden区被压得非常小，GC极其频繁，说明目标可能过于激进。

3.2 并发标记触发阈值：-XX:InitiatingHeapOccupancyPercent

这个参数（简称IHOP）控制何时启动并发标记周期，默认是45%。意思是当整个堆的使用率达到45%时，G1会开始后台的并发标记，为后续的Mixed GC做准备。

为什么这个参数至关重要？并发标记需要时间（通常不短）。如果触发得太晚，比如堆都用到80%了才开始标记，可能在标记完成前，应用就已经把堆分配满了，从而直接触发Full GC。如果触发得太早，又会不必要地占用CPU资源进行标记，影响应用吞吐。

调优建议：

• 对于对象分配速率高或堆内存很大（比如超过32G）的应用，建议适当降低IHOP。例如设置为35%或40%，给并发标记留出更充裕的时间窗口。
• 在JDK 9u40之后，G1引入了自适应IHOP（通过-XX:G1UseAdaptiveIHOP开启，默认开启）。G1会学习应用的行为，自动调整IHOP。在应用启动稳定后，这个功能通常效果很好。但在应用启动阶段或负载发生剧烈变化时，手动设置一个保守值作为起点更安全。

3.3 并行线程数：-XX:ParallelGCThreads与-XX:ConcGCThreads

• ParallelGCThreads：控制STW阶段（Young GC、Mixed GC的转移阶段）进行并行垃圾回收的线程数。默认值基于CPU核心数计算：ParallelGCThreads = (ncpus <= 8) ? ncpus : (8 + ((ncpus - 8) * 5 / 8))。对于多核机器，通常无需调整。
• ConcGCThreads：控制并发阶段（并发标记、并发清理）使用的线程数。默认值是ParallelGCThreads / 4。

调优建议：

• 除非你非常清楚自己在做什么，否则不要轻易改动。增加线程数会加快GC本身，但也会争夺应用线程的CPU资源。
• 一种典型的调优场景是：在CPU资源非常充裕（比如容器分配了8核，但应用平时只用4核），且GC停顿是主要瓶颈时，可以尝试略微增加ConcGCThreads（例如设为ParallelGCThreads / 2），以加快并发标记速度，降低因标记跟不上分配而引发Full GC的风险。

3.4 大对象处理：-XX:G1HeapRegionSize与 Humongous Region

如果一个对象的大小超过了一个Region大小的50%，它就会被认为是一个“巨型对象”（Humongous Object）。G1会为它分配连续的多个Region，这些Region被标记为Humongous Region，且在回收时，只有在Full GC时才会被处理。

这意味着什么？如果你的应用有大量短命的大对象（比如某个接口频繁分配几百KB的临时数组），它们会迅速占满Humongous Region，但又不会在常规的Young/Mixed GC中被回收，从而可能提前触发并发标记甚至Full GC。

调优实战：

1. 监控：查看GC日志，关注Humongous allocations和Humongous regions相关的信息。
2. 分析：如果发现Humongous分配频繁，且对象生命周期很短。
3. 对策：
   • 优化代码：这是根本。检查是否可以通过对象复用、调整数据结构来避免分配如此大的对象。
   • 调整Region大小：如果大对象的大小刚好略高于RegionSize的50%，可以考虑适当增大G1HeapRegionSize，使得这些对象不再被判定为Humongous，从而能被正常的GC回收。例如，默认RegionSize是8M，一个4.1M的对象就是Humongous；如果将RegionSize设为16M，它就不是了。
   • 权衡：增大RegionSize会减少Region总数，但可能影响内存的灵活分配。需要经过测试。

4. 一份生产级G1配置模板与参数解析

说了这么多理论，来看一个我用于某个中等延迟要求的微服务（堆内存16G）的配置示例。这不是银弹，但可以作为一个理解和调整的起点。

# 堆内存设置 -Xms8g -Xmx8g # 生产环境建议初始堆和最大堆设置相同，避免运行时扩容带来的性能波动。 # 使用G1垃圾回收器 -XX:+UseG1GC # 核心停顿时间目标，根据监控调整 -XX:MaxGCPauseMillis=150 # 并发标记触发阈值，为标记留出足够时间 -XX:InitiatingHeapOccupancyPercent=35 # 启用并行GC线程数自动调整（一般保持默认） # -XX:ParallelGCThreads=... # 稍微增加并发标记线程，加快标记速度（在16核机器上） -XX:ConcGCThreads=4 # 启用GC日志，这是调优的“眼睛”，必须开启 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy # 打印G1自适应调整的决策，对理解行为很有帮助 -Xloggc:/path/to/your/service_gc.log # 指定GC日志路径 # 当日志文件达到一定大小后滚动，避免撑爆磁盘 -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M # 在发生OOM时生成堆转储，便于事后分析 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/your/heap_dump.hprof # 禁用偏向锁，在并发高的微服务中通常能提升性能 -XX:-UseBiasedLocking # 启用字符串去重（JDK 8u20+），节省内存，但会消耗少量CPU -XX:+UseStringDeduplication

逐项解析与心得：

• -Xms和-Xmx相等：这可能是最重要的一个最佳实践。避免堆在运行时自动伸缩，这会导致不必要的GC和性能不稳定。
• PrintAdaptiveSizePolicy：这个日志开关非常有用。它会打印G1为什么调整年轻代大小（例如，“[G1Ergonomics (Heap Sizing) attempt heap expansion...”），让你看清G1是如何努力达到停顿时间目标的。
• UseStringDeduplication：对于处理大量文本（如JSON/XML解析）的服务，这个功能可以节省可观的内存。它通过额外的并发线程来查找并合并重复的字符串。如果你的应用CPU非常紧张，可以关闭它。

5. 从GC日志诊断常见问题与排查技巧

光有配置不够，必须学会看GC日志。下面是一段典型的Mixed GC日志，我们一起来解读：

2024-05-27T10:23:15.123+0800: 1023.456: [GC pause (G1 Evacuation Pause) (mixed) [Eden: 4096.0M(4096.0M)->0.0B(4096.0M) Survivors: 1024.0M->1024.0M Heap: 12.5G(16.0G)->10.1G(16.0G)] [Times: user=1.23 sys=0.12, real=0.25 secs]

• 1023.456：从JVM启动到现在的秒数。
• G1 Evacuation Pause (mixed)：这是一次Mixed GC。
• Eden: 4096M->0B：回收前Eden区有4G，回收后为0。
• Survivors: 1024M->1024M：Survivor区大小不变，但内部对象已经过拷贝和晋升。
• Heap: 12.5G->10.1G：整个堆回收前用了12.5G，回收后用了10.1G，释放了2.4G空间。
• [Times: user=1.23, real=0.25]：这是关键！user时间是所有GC线程消耗的CPU时间总和（1.23秒），real是实际的STW停顿时间（0.25秒）。因为GC是多线程并行工作，所以real时间远小于user时间。如果real时间持续超过MaxGCPauseMillis，就需要关注了。

常见问题排查清单：

一个关键的实操心得：调优是一个“观察-假设-调整-验证”的循环。永远不要一次性修改多个参数。每次只调整一个你认为最可能解决问题的参数，然后收集足够长时间的监控数据（至少覆盖一个完整的业务高峰周期）来观察效果。使用APM工具（如Pinpoint, SkyWalking）的JVM监控面板，结合GC日志分析工具（如GCeasy, G1GCViewer），可以让你事半功倍。

最后，我想强调的是，G1是一个高度自动化的、追求平衡的垃圾回收器。很多时候，“少即是多”。在充分理解其原理和监控数据之前，使用JVM默认的参数或仅做微调，往往比盲目套用网上搜来的“优化参数”要好得多。我的经验是，先给足内存（-Xmx），设置一个合理的停顿目标（MaxGCPauseMillis），并提前触发标记（降低IHOP），这三点做好，大部分应用的GC表现就已经在及格线以上了。剩下的精细调优，需要结合你独一无二的应用特性和负载模式来进行。