企业官网建设流程全解析

线上接口突然卡了几秒，CPU没有爆，内存却一直停在高位，查来查去最后定位到GC长停顿——这种情况我在服务端排查里遇到太多次了。GC优化听起来像个高深的技术活，但它解决的核心问题其实很朴素：让JVM在回收垃圾这件事上，少花时间、少停顿，把资源让给业务。很多人一上来就背G1、ZGC参数，结果调完更卡。这篇文章不讲虚的，从JVM内存模型到GC回收器选型，再到日志分析和参数配置，按我实际排查的思路一步步拆给你看。

1. GC优化的根基：先弄懂JVM内存模型和对象的一生

1.1 堆内存分区：新生代、老年代与元空间

GC优化的第一步不是调参，而是先搞清楚JVM在管哪些地。Java堆内存虽然逻辑上是一块连续区域，但实际运行时被划分为新生代、老年代和元空间（JDK 8以后PermGen被替换成Metaspace）。新生代里又分成Eden区、From Survivor和To Survivor两个存活区，比例默认是8:1:1，当然这个比例可以通过参数调整。

对象分配时绝大多数先进Eden区，Eden活下来的对象经过一轮Minor GC后被搬到Survivor区。Survivor区之间每次Minor GC都会交换身份，谁空谁当To区。当对象在Survivor区中熬过了默认15次回收，或者存活对象大小超过Survivor区容量的一半，就会被晋升到老年代。老年代里的对象生命周期长，回收频率低，但一旦发生GC就是Major GC或Full GC，停顿时间往往比Minor GC长得多。

这套分区设计是有讲究的。新生代用复制算法，因为大部分对象朝生夕死，只复制少量存活对象效率高，而且没有内存碎片。老年代用标记-清除或标记-整理，因为对象存活率高，复制代价太大。理解这个分区，后面分析GC日志时才能一眼看出问题出在哪。

1.2 对象被回收的判断标准：可达性分析

JVM判定对象是否可回收，不是看引用计数，而是从一组称为GC Roots的根对象出发，一路遍历引用关系。凡是不可达的对象，会被标记为可回收。GC Roots包括栈帧中的局部变量、静态变量、JNI引用、活跃线程等。这就是为什么一个对象即使没有显式置空，只要还被某个局部变量引用着，它就不会被回收。

同时Java的引用类型分强引用、软引用、弱引用、虚引用。强引用是普通new出来的对象，JVM宁可抛OOM也不会回收它；软引用在内存不足时才回收；弱引用在下一次GC时就会被回收；虚引用主要是配合引用队列做资源释放。很多内存泄漏问题其实不是GC不给力，而是强引用被容器、静态集合、ThreadLocal等不小心长期持有，GC怎么优化都绕不过去。

所以我在给团队做GC优化培训时，经常开玩笑说：GC优化像打扫房间，JVM是保洁员，但绝对不能让保洁员解决“你在屋里堆满杂物还不扔”的问题。业务代码里的无界缓存、未关闭的连接、监听器没有移除，这些才是Full GC频繁的幕后黑手。

1.3 Minor GC、Major GC与Full GC的区别

很多新手分不清Minor GC和Full GC。Minor GC发生在新生代，频率高、速度快，清理掉大量短命对象。Major GC一般指清理老年代，而Full GC则是清理整个堆，包括新生代、老年代和元空间。在实际日志里，Full GC往往是最让人头疼的，因为它意味着所有业务线程都要进入安全点，停顿动辄几百毫秒甚至几秒。

不同的GC回收器对Full GC的触发条件也有差异。比如CMS回收器在老年代占用达到一定阈值时会触发后台并发收集，如果并发回收期间内存不够，就会出现“Concurrent Mode Failure”，降级为Serial Old单线程Full GC，停顿非常恐怖。G1也有类似的Evacuation Failure导致Full GC的情况。所以排查Full GC，不能只看频率，还要看触发前后堆占用变化、回收器类型、以及是否存在晋升失败等异常路径。

2. 主流JVM GC回收器选型：从Serial到ZGC，选对才能少踩坑

2.1 每代回收器到底解决了什么痛点

JVM里的GC回收器经过多次迭代，从最初的Serial、Parallel，到CMS、G1，再到现在的ZGC和Shenandoah。Serial是最古老的单线程回收器，适合客户端到单核小堆场景，平时服务端基本用不到。Parallel追求吞吐量，是JDK 8默认的回收器，适合后台计算任务，比如离线批处理，能容忍短停顿换更高的处理量。

CMS是第一个真正意义上的并发回收器，目标就是减少停顿，但它的缺点很致命：使用标记-清除产生内存碎片，并发阶段会占用CPU，最怕并发模式失败。G1从JDK 9开始成为默认回收器，它把堆划分为多个Region，通过预测停顿时间模型，在吞吐量和停顿之间做了折中。ZGC则是低延迟方向的极致选择，停顿时间几乎控制在10毫秒以内，JDK 21里甚至把GC停顿压缩到微秒级，适合超大堆和延迟敏感业务。

选型时最忌直接照搬别人的参数。我见过很多团队从Java 8升到Java 11后，还是用老一套CMS参数，结果把G1调得乱七八糟。一定要先理解业务是吞吐敏感还是延迟敏感，再决定用哪一个回收器。

2.2 吞吐量优先还是停顿时间优先

这是选回收器时最核心的取舍。吞吐量指的是运行用户代码的时间占总CPU时间的比例，Parallel追求的就是这个，它牺牲停顿时间来换高吞吐。延迟敏感业务更关注最大停顿时间，比如支付、游戏、交易链路，用户不会容忍接口因为GC暂停500毫秒。

如果用表格对比，会更直观：

在JDK 8时代，如果业务接口RT超过300毫秒就会报警，我通常优先尝试G1。如果是JDK 17以上的新服务，堆内存又超过32GB，直接上ZGC反而省心。不过记住，GC回收器只是工具，不是升级到ZGC就万事大吉，业务代码里的问题它解决不了。

2.3 业务类型决定回收器，而不是参数决定

有一次帮朋友排查一个游戏排行榜服务，JVM参数里堆开到了16GB，用的是CMS，结果高峰期每次Full GC停顿近2秒，玩家直接感觉卡顿。后来我仔细看了对象分配情况，发现大量短命对象在Eden区频繁创建，Survivor区太小导致对象提前晋升老年代，老年代一满就触发Full GC。这已经不是回收器选型问题，而是对象分配节奏和堆比例配置问题。

后来换成G1，把最大堆降到8GB，同时调整了Region大小和新生代初始占比，让短命对象尽量在新生代被回收。最终Minor GC次数下降了一半，Full GC从每分钟几次降到几乎为零。这个案例说明，回收器选型只是第一步，更关键的是结合业务对象生命周期去配置堆和代码层面减少分配压力。

3. GC优化实操：从GC日志到JVM参数，一整套可复制的打法

3.1 先开GC日志，别凭感觉优化

我见过不少工程师调GC参数靠猜，调完看监控数字说“好像好了一点”。这种优化方式纯粹靠运气。真正的GC优化第一步永远是打开GC日志，拿到第一手的回收频率、停顿耗时、堆占用数据。

JDK 8可以加上这组参数：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:/data/logs/gc.log

JDK 11及以上推荐统一用Xlog：

-Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags

日志里能看到每次GC的类型、回收前后堆占用、停顿耗时、用户态和内核态耗时。配合GCViewer或在线分析工具，可以直接看出Minor GC频率、晋升大小、Full GC触发位置。没有日志，后面的所有分析和参数调整都是盲人摸象。

3.2 关键JVM参数拆解：每个参数背后都是权衡

GC优化相关的JVM参数很多，但真正经常动的是这么几个：

• -Xms和-Xmx：初始堆和最大堆。生产环境推荐两个值设一样，避免运行时堆扩容造成额外停顿。
• -Xmn：新生代大小。太大可能导致老年代过小，晋升频繁触发Full GC；太小又会加速对象晋升。经验值一般占堆的1/3到1/4。
• -XX:SurvivorRatio：Eden区和Survivor区的比例。默认8，也就是Eden占新生代的8/10。如果Survivor区频繁溢出，可以调成7或6。
• -XX:MaxTenuringThreshold：对象晋升老年代的年龄阈值。默认15，但如果每次Minor GC后对象占用很高，可以降低这个值，避免Survivor区反复复制。
• -XX:+UseG1GC：启用G1。配合-XX:MaxGCPauseMillis设置期望停顿目标，比如200毫秒。
• -XX:InitiatingHeapOccupancyPercent：G1触发并发标记周期的堆占用阈值，默认45。如果这个值太低，会频繁启动并发标记；太高又容易导致并发回收跟不上。

举一个实际项目的启动参数例子：

java -Xms8g -Xmx8g -Xmn3g -XX:SurvivorRatio=8 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=60 -XX:ConcGCThreads=4 -Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags

这套配置的思路是：堆固定8GB，新生代给3GB，保证短命对象在新生代尽量被消化；G1的目标停顿设在200毫秒，老年代占用到60%才开始并发标记，避免频发启动标记线程；并发GC线程数压到4，避免和业务线程抢CPU太厉害。

3.3 调优三部曲：观察-假设-验证

我把GC调优总结成反复循环的三步。观察阶段，通过GC日志和监控平台收集指标，比如Minor GC平均间隔、每次回收后堆占用、Full GC频次、暂停时间分布。假设阶段，根据数据形成判断，比如“Survivor区过小导致对象提前晋升”，或者“某段代码在频繁创建大数组导致Eden直接压力大”。验证阶段，改参数或改代码后重新上线，用同一时间段的数据对比。

这个过程特别要注意一次只改动一个变量。很多人喜欢一次性动堆大小、回收器、比例阈值，结果出了效果也不知道是谁的功劳，出了问题更是无从回滚。正确的做法是每改一个参数观察至少一个业务周期，比如流量高峰过去后，看GC曲线和业务RT是否有真实改善。

3.4 参数调整不是越多越好，少改动才有安全感

还有一点，GC参数不需要把网上所有技巧都加进去。很多参数是平台内部根据JDK版本和回收器自动调整的，手动覆盖反而限制了JVM的自我调节能力。比如-XX:NewRatio不要和-XX:MaxNewSize混用，-XX:MaxGCPauseMillis设得太小会导致G1频繁调整新生代大小，反而增加开销。

我个人的原则是：先固定堆大小，再定回收器，之后只调整三到四个直接影响现象的参数。如果日志显示晋升压力大，优先调SurvivorRatio和MaxTenuringThreshold；如果Full GC触发频繁，再考虑InitiatingHeapOccupancyPercent和并发线程数。改完必须留观察窗口，一切以线上数据说话。

4. 实战案例：一次线上接口P99飙升的GC排查全过程

4.1 现象：接口变慢，老年代占用居高不下

一次线上促销活动前，订单查询接口的P99从原来的80毫秒飙到800多毫秒，但P50和P75变化不大，明显是有少量请求经历了长停顿。我第一时间打开监控面板，发现老年代占用一直维持在85%以上，Full GC每天触发几十次，最严重的停顿接近1.5秒。再看内存曲线，每次Full GC回收后老年代能降下来，但过十几分钟又慢慢涨回去，典型的“老年代持续堆积，回收跟不上分配”。

这里要区分是内存泄漏还是对象分配峰值过高。如果Full GC后老年代可以回到低位，只是之后逐步涨上来，通常不是泄漏，而是有大量中长生命周期对象产生。如果Full GC后老年代占用不下降，那才要怀疑泄漏。我们当时的现象属于前者，所以思路放在降低晋升率和老年代压力上。

4.2 定位：用jstat和GC日志确认问题链路

排查时我用了一组很基础的工具。先执行jstat -gcutil <pid> 1000，每秒看一次Eden、Survivor、老年代的使用率和GC次数。很快发现Eden区每隔几秒就触发一次Minor GC，每次Minor GC后Survivor区占用很高，然后很多对象被晋升到老年代。这里的关键是Survivor区根本接不住Minor GC后还活着的对象。

接着看GC日志里的Tenuring Distribution信息，发现大量对象在年龄只有1到2岁时就被晋升到了老年代。正常情况下，短命对象应该在Eden区大批量死亡，只有少部分年龄增长。现在这个现象说明要么对象本身比较大（比如几MB的数组），要么是Survivor区容量不够导致提前晋升。我再配合jmap -histo:live <pid>看堆内存里什么对象最多，发现排在最前面的是某个缓存框架的过期条目结构体，单条记录就占了接近100KB。

4.3 剖析：缓存框架导致老年代膨胀

这个缓存框架的过期清理线程是懒删除策略，读取时才检查过期，但促销场景下大量请求写入缓存，导致堆积。虽然框架有最大容量限制，但在接近阈值时，对象会先被写入，再异步清理，中间这段时间就会大量占用内存。到了GC眼里，这些对象年龄增长后被晋升老年代，而老年代的并发标记始终赶不上堆积速度。

这里其实有两个优化方向。方向一，调整GC参数增加Survivor区，降低晋升率；方向二，从业务代码层面限制缓存过期时间，或者改用堆外缓存，减少JVM堆压力。我最后两个方向都做了：把新生代从2GB调到3GB，并将MaxTenuringThreshold从15降到5，让实在活不过几轮的对象别在Survivor区反复复制；同时把缓存框架的容量下调20%，增加强制的定期清理任务。两周观察下来，Full GC完全消失，P99回落到120毫秒以内。

4.4 结果：GC优化不是单靠参数，代码和参数要打配合

这次排查看下来，真正解决问题的是代码层面的缓存策略调整，参数优化只是给GC腾出了更多缓冲空间。很多GC问题是业务代码带来的压力暴露了JVM的配置缺陷，如果只调参数不碰代码，顶多是把问题往后拖延，下一次流量高峰照样爆发。所以我的习惯是：变量监控、GC日志、堆转储三者结合，先定位到具体代码链路，再决定要不要动参数。

同时也说明，GC优化并没有一招鲜的配置，必须在自己的业务场景里反复“观察-假设-验证”。不同团队、不同接口、不同并发模型，即使跑在同样的JDK版本上，最适合的参数也可能完全不同。

5. GC优化避坑指南：容易翻车的地方我替你踩过了

5.1 常见GC问题速查表

我在实际排查中把高频问题整理成了一张速查表，很适合在外卖文档里用：

这张表不能直接当结论，但可以快速给出方向，减少盲猜的时间。每次遇到GC问题，先用几分钟对号入座，然后再深入看日志。

5.2 三个反直觉的“坑”

第一个坑是堆内存设得越大越好。堆太大确实能降低GC频率，但单次GC扫描的Region更多，停顿时间反而可能变长。尤其是G1在超大堆下，如果不设置Region目标大小，Full GC风险反而更高。所以要找到“堆够用”和“GC可接受”之间的平衡点，而不是无限加内存。

第二个坑是System.gc()被隐式触发。很多框架和工具链会调用System.gc()，如果没加-XX:+DisableExplicitGC，完全可能意外触发Full GC。我就遇到过Netty的堆外内存申请失败后回调System.gc的情况，导致服务每隔一段时间就卡死一次。生产环境除非明确知道自己在做什么，否则建议禁用显式GC。

第三个坑是绕过GC看问题，只看CPU和内存不结合GC日志。GC停顿往往不是CPU高，而是业务线程在安全点被挂起，从外部看起来只是RT变长。如果不看GC日志，很容易误判为数据库慢查询或网络问题，白白浪费排查时间。

5.3 GC优化做到什么程度才算结束

很多人一旦开始调GC，就停不下来，总觉得还能再压一点停顿。我的判断标准很简单：看业务指标。对于接口型服务，只要GC停顿不对RT的P99产生明显影响，GC优化的收益就已经到位了。对于批处理任务，只要不因为GC拖慢整体执行时间，剩下的全交给JVM默认参数即可。

GC优化的终点是让JVM“不抢戏”。当堆内存曲线平稳、Full GC消失、业务指标达标，这就算是完成了一次成功的调优。后续要做的是建立监控和告警机制，比如老年代占用超过70%持续5分钟，或者Full GC超过3次/min就告警，这样问题能在爆发前被发现，而不是等用户反馈。

最后说一点个人体会。做GC优化这些年，我最深的感受是：绝大多数线上GC问题，靠的不是某个神奇的参数，而是把基础原理搞清楚，再耐心地看日志、做对比、小步验证。数据比感觉可靠，业务指标比单一技术指标更值得守护。如果你正准备在项目里做GC优化，别急着抄配置，先把你服务的GC日志打开，记录一周现状，然后从最明显的异常开始，一点点调。这个过程可能很枯燥，但线上系统给你的回报，往往远超想象。