“线程全部卡住，接口响应全红了，CPU占用却不高，服务像死了一样。”这是上个月一个用户量不算小的线上服务出故障时，我在监控大屏上看到的现象描述。故障持续了几十秒，之后一切恢复正常，仿佛什么都没发生过。但就是这几十年一遇的“时间静止”，让我把排查重心从网络、锁竞争一路拉到了JVM垃圾回收（GC）上。GC导致的长时间停滞，在Java服务端是出了名的隐形杀手，它不像OOM那样直接崩溃，也不像死锁那样完全不可用，而是以“周期性假死”的方式存在，极难复现，也极难定位。这篇文章，我就用一次真实的诊断过程，把JVM垃圾回收停滞背后的原理、工具和排查思路完整拆一遍。无论你是刚接触JVM调优的开发者，还是已经在用G1或者ZGC的资深工程师，这套方法论应该都能帮你少走很多弯路。
1. 先搞清楚：GC停顿到底是怎么回事
1.1 “时间静止”在JVM里是怎么发生的
JVM里的垃圾回收并不是一边回收、一边让业务线程照常运行的。为了保证对象引用关系的正确性，绝大多数回收动作都需要在“所有业务线程全部暂停”的状态下进行，这就是我们常说的Stop-The-World，简称STW。STW期间，应用线程完全冻结，用户请求排队等待，表现就是接口超时、服务无响应，严重的时候甚至会让负载均衡器误判服务宕机，直接把节点摘掉。
很多刚接触JVM的人会有一个误解：STW只发生在Full GC的时候。实际上，即便是号称“并发回收”的CMS（Concurrent Mark Sweep）或者G1，也包含多个必须STW的阶段。比如G1的初始标记（Initial Mark）、最终标记（Final Mark）、混合回收（Mixed GC）的转移阶段，都需要暂停业务线程。区别只在于暂停时间的长短和频率。换句话说，完全的“无停顿”在目前主流的回收器里是不存在的，只是把停顿控制得更短、更分散而已。
“时间静止”这个词，用来形容GC引发的服务假死非常贴切。一次几秒钟的Full GC就能让一个日活百万的服务在用户侧“蒸发”几十秒，这在交易、支付、实时推荐这类场景下是致命的。所以，理解GC停顿，核心就是理解STW发生在哪、持续多久、为什么这么久。
1.2 停顿的层次：从毫秒级到分钟级
GC停顿在影响面上分三个层次，实际排查时经常混淆。第一层是Minor GC/Young GC停顿，通常几十毫秒以内，影响有限，但频率高的时候同样会造成吞吐量下降。第二层是Old GC/Full GC停顿，从几百毫秒到几秒都有可能，这通常伴随着堆内存压力过大、晋升速率过快或者回收器配置失当，是线上“时间静止”的主要来源。第三层是JVM本身之外的系统级停顿，比如操作系统内存交换（Swap）、频繁的Page Cache写回、容器CPU限流等，这类问题在GC日志里看不出来，但症状和GC停滞几乎一样，排查时要纳入考虑范围。
不同层次的停顿，排查思路完全不同。Young GC频繁，往往和新生代太小、对象分配速率太高有关；Full GC时间长，就要看是老年代满了、元空间膨胀了，还是出现了大对象（Humongous Object）导致GC压力剧增；如果GC日志正常但服务还是卡顿，那就要往操作系统和硬件的方向查。诊断的第一步，应该是先确定你遇到的到底是哪一个层次的停顿，而不是盲目堆内存或者换回收器。
1.3 为什么线上问题总是很难复现
GC停滞类的故障和普通Bug最大的差异在于：你很难在测试环境复现同样规模的停顿。原因有三点。第一，测试环境的QPS和线上差一两个数量级，对象分配速率不同，GC行为就完全不同。第二，数据特征不同，线上存在大量特定模式的对象，比如大数组、缓存、长生命周期对象，这些在测试数据里很难模拟。第三，JVM的即时编译（JIT）需要时间预热，短时间压测时JIT还没完成优化，GC行为也和长时间运行的线上实例有明显差异。
这就决定了诊断GC问题的方法论必须回到现场：GC日志、堆转储（Heap Dump）、线程快照（Thread Dump）、监控指标，缺一不可。下面我会完整演示一次实际排查过程，你可以直接套用这套流程。
2. JVM内存模型与回收器选型，决定你遇到哪种“停滞”
2.1 堆内存分区是理解一切的基础
JVM的堆内存（Heap）按代际划分，典型结构是新生代（Young Generation）和老年代（Old Generation）。新生代里又分为Eden区和两个Survivor区（S0、S1），比例默认是8:1:1（通过-XX:SurvivorRatio调整）。新对象分配在Eden区，Minor GC时存活对象通过复制算法在两个Survivor区之间来回拷贝，每次拷贝年龄加一，超过-XX:MaxTenuringThreshold（默认15）后晋升到老年代。
理解这个模型的意义在哪里？GC停滞的根源几乎都能在这套分区体系里找到。比如Eden区过小，Minor GC就会很频繁；Survivor区过小，大量对象来不及熬过年龄阈值就被提前晋升到老年代，进而触发Full GC；老年代持续高位，CMS或者G1的并发周期就会一直跑，并发失败后还会退化成Serial Old式的串行Full GC，停顿时间暴涨。很多JVM调优其实就是在调这三个区域的容量配比，让对象在新生代“多活几个轮回”，减少晋升压力。
这套“分代收集”理论并不是Java独有的，像C#的垃圾回收也采用了类似的分代策略。Java和C#在这方面思路相近，但JVM的回收器实现更丰富，参数更复杂，这也是同一个问题在Java生态里更容易被讨论、也更容易出事故的原因。
2.2 回收器家族谱系：从Serial到ZGC
JDK各个版本内置了多款垃圾回收器，选型直接影响你的停顿表现。Serial最古老，适合单线程、堆内存极小的场景，比如客户端应用；Parallel是JDK 8默认回收器，强调吞吐量，适合后台批处理，但Full GC时停顿明显；CMS从JDK 9开始废弃，JDK 14移除，它的并发标记清理思路在当时很先进，但碎片化和并发模式失败是硬伤；G1从JDK 9开始成为默认，主打可预测的停顿时间模型，通过把堆划分为多个Region，优先回收垃圾最多的Region，是目前服务端主流；ZGC和Shenandoah则是超低停顿回收器，ZGC的停顿时间可以控制在10ms以内，适合超大堆场景，JDK 15之后逐步成熟。
选回收器本质上是在吞吐量、停顿时间、内存占用、实现复杂度之间做权衡。Parallel把吞吐量做到极致，代价是STW时间长；G1牺牲少量吞吐量换取更可控的停顿；ZGC为了低停顿，额外增加了内存屏障和着色指针等开销。没有“最好的回收器”，只有“最适合业务特征的回收器”。比如你是个跑批任务的后端服务，对延迟不敏感，Parallel GC反而更合适；如果是在线交易系统，G1或者ZGC更匹配。
2.3 不同回收器的“暂停”特征对比
我刚入行那会儿，经常把CMS和G1混为一谈，觉得都是并发回收器，停顿时间应该差不多。实际上差异非常大。CMS的并发标记和并发清理阶段确实不暂停业务线程，但它的初始标记和重新标记需要STW，最重要的是，CMS在并发清理时如果老年代被业务线程写满了，会触发Concurrent Mode Failure，直接退回Serial Old进行串行Full GC，这个停顿经常是十几秒起步。
G1的思路是把堆切成一个个Region，通过追踪每个Region的垃圾堆积价值，在满足停顿时间目标-XX:MaxGCPauseMillis的前提下，选垃圾最多的Region优先回收。G1的Young GC需要STW，但停顿时间通常远低于Parallel；它的Mixed GC会并发标记+STW转移垃圾最多的Region。G1最怕的是大对象分配，如果一个对象超过Region大小的50%，会被直接分配进连续的巨型Region（Humongous Region），这种对象回收压力很大，很容易导致Full GC。
至于ZGC，它把STW时间压缩到了极致，染色指针和读屏障让绝大部分回收工作都能和应用线程并发进行。但我个人不建议一上来就用ZGC，因为它的CPU开销相对更高，而且对堆内存大小和JDK版本有要求，核心业务建议在充分压测后再上。下面用一个表格直观对比主流回收器的停顿特征。
| 回收器 | 主要STW阶段 | 典型停顿时间 | 适用场景 | 主要风险 |
|---|---|---|---|---|
| Serial | Young GC / Full GC全程 | 数十ms~数s | 客户端、极小堆 | 停顿不可控 |
| Parallel | Young GC / Full GC全程 | 数十ms~数s | 批处理、吞吐优先 | Full GC长停顿 |
| CMS | 初始标记/重新标记 | 数百ms级 | JDK 8时代在线服务 | 碎片化、并发模式失败 |
| G1 | Young GC / Mixed GC转移 | 数ms~数百ms | JDK 9+在线服务 | 大对象、转移失败 |
| ZGC | 极少数阶段 | <10ms | 超大堆低延迟场景 | CPU开销较高 |
对大部分团队来说，当前最优解基本上是在G1和ZGC之间做选择。JDK 8上跑CMS的老项目，建议优先升级到JDK 17+并切换到G1，收益非常明显。
3. 深度诊断实操：一次Full GC长时间停顿的完整排查
3.1 故障现场：现象、监控与第一反应
回到开头那个线上故障。监控数据显示，服务在晚上八点准时出现一次长达40多秒的无响应窗口，期间CPU使用率反而下降到接近0，内存使用率接近95%。故障结束后一切恢复，GC指标出现一次明显的异常峰。这种“CPU低、内存高、定时出现”的组合，几乎立刻让我锁定了方向：不是死锁（死锁时CPU通常也低，但不会周期性出现），也不是网络问题（网络故障不会这么规律），大概率是GC停滞，而且很可能是Full GC。
第一反应不要急着重启机器或者加内存。正确做法是先把证据拿到手。我立刻执行了三件事：确认GC日志是否开启，查看监控系统里最近一小时的Full GC次数和时间，记录下故障发生前后的存活对象情况。如果GC日志没开，后面一切都是盲人摸象。这也是我一直强调的，生产环境JVM参数里-Xlog:gc*这类日志开关必须打开，哪怕你觉得永远用不上。
如果你的服务已经出现Full GC但GC日志开关没开，也不是完全没办法。可以通过jstat -gcutil <pid> 1000每秒钟采样一次堆内存使用率和GC耗时，能大致定位到Full GC的时间点，但看不到完整的GC Cause和对象统计，定位起来会慢很多。所以我的习惯是：只要是长期运行的服务，GC日志和必要的转储开关一律在启动参数里配好。
3.2 用GC日志还原“案发经过”
拿到GC日志之后，第一步是看GC Cause。GC日志里每个GC事件都会标注触发原因，常见的包括Allocation Failure（分配失败）、Metadata GC Threshold（元空间达到阈值）、System.gc()（显式调用）、Ergonomics（JVM自适应调整）、G1 Humongous Allocation（G1大对象分配）。如果是System.gc()，那就去搜代码里哪里调用了System.gc()或者Runtime.getRuntime().gc()，很多框架比如Netty、RMI都可能在特定条件下触发，这类Full GC是“人祸”而不是“天灾”。
我那一次排查到的原因就是G1 Humongous Allocation，翻译过来是“巨型对象分配失败导致Full GC”。日志里频繁出现类似G1 Humongous Allocation的Cause，并且伴随Pause Full (G1 Humongous Allocation)事件。所谓大对象，指的是大小超过G1 Region Size一半的对象-XX:G1HeapRegionSize默认会根据堆大小自动调整，通常在1MB到32MB之间。如果一个大对象超过这个阈值，G1无法把它放进普通的Region，只能占用连续的巨型Region，而这些巨型Region一旦堆空间紧张，就会直接触发Full GC。
接下来要做的就是从堆转储或者代码路径里定位是什么对象这么大、谁分配的。这一步需要和业务代码特征结合。我当时通过jmap -histo:live <pid>和jmap -dump:live,format=b,file=heap.hprof <pid>拿到了堆转储，用MAT（Memory Analyzer Tool）分析后发现，罪魁祸首是一个2MB大小的byte[]数组，由某个报表导出功能创建。这个导出功能每次执行都会把一批数据全量加载到内存，然后一次性写入响应流，QPS一高，立刻制造大量大对象。
3.3 结合堆转储与线程快照锁定元凶
拿到堆转储之后，别直接看Dominator Tree（支配树），先看Histogram（直方图）。按对象总大小排序，一眼扫过去，byte[]、char[]、Object[]这几类占用最高的往往就是问题所在。然后用“Find Object by Name”或者“Search for unreachable objects”查一下这些大对象是从哪个线程、哪段业务逻辑分配出来的。MAT的“Thread Overview”和“Leak Suspects”能帮你快速定位到可疑的调用链。
线程快照（Thread Dump）在这个场景里同样有价值。GC停顿期间所有的业务线程都卡住，线程栈里能看到线程当前处于什么锁等待或者代码执行状态。如果多次取样，发现大量线程停留在某个对象分配相关的代码路径上，比如在byte[]的分配处、在某个流的读取处，那基本可以确定这些线程正在刺激堆内存不断分配新对象。我当时在故障时间段抓了三次jstack，发现大量线程停在FileOutputStream.write一个报表导出的路径上，和堆转储的结果互相印证。
诊断到这一步，根因已经很清楚了：一个占用大内存的报表导出接口在高峰期集中被调用，制造了大量G1巨型对象，这些对象占用大量连续Region，触发G1 Humongous Allocation类别的Full GC，最终表现为整个服务“时间静止”40秒。
3.4 参数调整与效果验证
根因是业务代码的分配特征太差，所以治本方案是改代码：报表导出改成流式查询加分批写入，避免一次性把全量数据装进内存；对于大对象，能拆就拆，拆不掉就考虑使用堆外内存。在你改完代码之前，JVM参数可以做几件事来缓解症状。
第一，调大-XX:G1HeapRegionSize，让大对象不再被视为巨型对象。比如把Region Size从默认的2MB提高到4MB，那么2MB的数组就不会再触发巨型分配。但要注意，Region Size越大，G1的粒度越粗，停顿时间目标的控制精度会下降，不要盲目调到32MB。第二，适当调大新生代-Xmn，给短命大对象更多周转空间，尽量减少直接晋升老年代的概率。第三，设置-XX:MaxGCPauseMillis并监控Mixed GC是否达标，但不要把这个值设得过低，否则G1会为了迎合目标而频繁进行GC，反而降低吞吐量。
修改参数后，我观察到Full GC的频率从每半小时一次降到两天一次，Pause时间从40秒降到200毫秒以内。在业务代码优化上线后，Full GC基本消失，服务恢复稳定。这次排查看似走了很多弯路，但事后复盘，真正高效的路径其实很清晰：监控发现特征模式，GC日志定位Cause，堆转储锁定对象，代码确认分配路径，参数缓解+代码根治。这套流程在之后的多次GC问题诊断里反复验证有效。
4. 常见问题排查实录与避坑指南
4.1 高频问题速查表
在我处理过的GC问题里，有一批问题出现频率极高，很多人反复踩坑，这里整理成一张速查表，方便直接对照。
| 症状 | 常见原因 | 诊断方向 | 处理建议 |
|---|---|---|---|
| Full GC频繁但堆内存不高 | 元空间达到阈值 | 查看Metadata GC Threshold | 调大-XX:MetaspaceSize和-XX:MaxMetaspaceSize |
| Full GC后内存占用依然很高 | 对象未被真正回收 | 检查堆转储中的GC Roots | 排查静态集合、缓存、ThreadLocal泄漏 |
GC日志中出现System.gc() | 代码显式调用或框架触发 | 搜索代码和依赖 | 删除显式调用，或者加-XX:+DisableExplicitGC |
G1出现Humongous AllocationFull GC | 大对象分配过多 | 堆转储定位大对象 | 代码层拆分大对象，调大Region Size |
出现Allocation Failure频繁Young GC | 新生代过小或分配速率过高 | jstat观察Eden区使用率 | 调大新生代，优化对象分配逻辑 |
| 服务卡顿但GC日志正常 | 系统级寄顿 | 检查Swap、CPU限流、IO等待 | 排查操作系统和容器资源配置 |
| JVM堆内存耗尽，Gradle构建失败 | 构建工具守护进程堆不足 | 查看Daemon日志 | 调整gradle.properties中的jvmargs |
| 开发工具频繁OOM | IDE堆内存配置不足 | 查看IDE日志 | 在IDE配置中调大-Xmx |
有一类问题是很多人在开发阶段就会遇到的，比如运行Gradle构建时出现expiring daemon because jvm heap space is exhausted，这表示Gradle守护进程（Daemon）的堆空间耗尽了。和线上服务不同，这是构建工具的堆配置问题，通常改一下gradle.properties里的org.gradle.jvmargs=-Xmx2048m就能解决。还有人在IDE启动时看到cannot collect jvm options caused by...的报错，这种多数是指向的JVM配置文件路径有问题，或者配置参数格式不对，跟运行时GC是两码事，但都属于JVM调优范畴里的“日常小坑”。
4.2 排查工具使用心得
工欲善其事，必先利其器。GC诊断常用的工具有这么几个，我会在每次实战里组合使用。jstat是第一个要用的，jstat -gcutil <pid> 1000能实时看到Eden、Survivor、Old、Metaspace的占用百分比和GC次数、耗时，适合快速判断当前GC压力。jmap用于查看堆内存分布和导出堆转储，-histo适合快速概览，-dump适合做深度分析。jstack在GC期间抓线程快照，配合GC日志能还原暂停期间业务线程的状态。MAT和VisualVM是堆转储分析工具，VisualVM适合快速看概览，MAT适合做泄漏分析，用Leak Suspects能自动判别可疑对象。
还有一个很多人忽略的组合技：jcmd。它是JDK 7之后自带的多功能命令，可以打印堆信息、GC统计、JIT编译状态，还能触发JFR（Java Flight Recorder）录制。jcmd <pid> GC.heap_info和jcmd <pid> GC.class_histogram是jmap的现代替代方案，在部分受限环境里更安全。JFR则是终极武器，-XX:StartFlightRecording可以在不重启JVM的情况下持续记录GC、JIT、锁竞争、IO等所有热点数据，事后用JMC（Java Mission Control）分析，很多“偶发性”问题都可以通过JFR捕获。
我个人在排查GC问题时，最推荐的工作流是：先用jstat确定GC压力级别，再开JFR做一次短时录制（10分钟到1小时），把GC事件、线程状态、分配速率全部记录下来，然后用JMC打开，直接看GC的Pause时间和分配压力曲线。JFR的开销非常低，生产环境长期开启也没问题，这是目前Java生态里最接近“一劳永逸”的监控方案。
4.3 日常开发中的JVM配置提醒
前面讲的都是线上问题，但JVM配置其实从日常开发阶段就应该打好底子。很多人习惯把IDE的堆内存设得很小，结果Indexing和编译期间频繁触发Young GC，整个IDE卡到怀疑人生。主流配置建议是：IDEA里在Help菜单下的Change Memory Settings处把堆内存调到2GB到4GB之间，具体看本机内存。Gradle构建时在gradle.properties里设置org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=1024m，能避免大部分构建时的OutOfMemory问题。
理解JRE和JVM之间的关系也有助于排查。JDK里包含JRE和一堆开发工具，JVM是JRE的核心执行引擎。我们说的JVM调优，调的是运行Java字节码的那个虚拟机的行为参数。IDE和Gradle这类工具本身也是跑在JVM上的Java程序，所以它们同样需要合理的堆配置，不然就会出现开发阶段特有的“JVM假死”。很多人以为“JVM调优”是线上才需要做的事，实际上，线上问题的很多隐患在开发阶段就埋下了，比如测试环境堆内存配得很大，掩盖了代码里的内存缺陷，一上生产就原形毕露。
另外说一句关于jvm面试题的。这类问题现在面试官尤其爱问：JVM内存模型是什么？GC回收器有哪些？G1和CMS有什么区别？实际工作中如果你真的处理过GC停滞，回答这些问题时能讲出真实的故障场景、分析过程和参数调整依据，比背十遍八股文都有说服力。写这篇文章，也是希望能帮你在面对“为什么系统会突然卡住”这类经典问题时，真的能从GC的角度给出有理有据的答案。
5. 写在最后的排查心法
这次“时间静止”故障处理完之后，我在复盘文档里写了一段话，很适合作为结尾分享给正在读这篇文章的你。排查GC停滞这类问题，最大的障碍不是工具不会用，不是参数记不牢，而是心态。故障一旦发生，所有人都在催你“赶紧恢复”，这个时候最容易做出的错误决策是重启大法——先重启再说。但重启会让所有现场证据灰飞烟灭，如果根因是代码里的大对象分配逻辑，重启十次也解决不了，下一次高峰期故障会准时复发。
正确做法可以分四步走。第一，稳定情绪，抓现场，确认GC日志和监控是否就位，不行就现开。第二，利用监控和日志找出故障规律，是周期性还是随机性，是跟流量高峰相关还是跟特定业务操作相关。第三，用GC Cause和堆转储锁定根因类别，再结合代码定位细节。第四，先通过参数调整缓解症状，同时安排代码修复上线。
我自己的经验是，一个稳定的JVM服务，70%靠合理的参数，30%靠代码质量。参数不合理，再好的代码也会在流量冲击下现原形；代码分配模式差，参数调得再漂亮也只是拖延问题。真正的高效团队，会把GC日志、堆转储、JFR这些基础能力在服务上线第一天就配置好，而不是等故障发生后才想起来。真正能让你在“时间静止”里快速苏醒的，不是运气，是你提前布下的观察能力和一套持续演练过的排查方法论。
