企业官网建设流程全解析

写这篇东西之前，先说点大实话：JVM垃圾回收器这四个字，可能是很多Java开发又爱又恨的考点。面试必问，线上出问题必查，但真要自己动手配置、调优的时候，又容易被各种名词搞懵。Serial、Parallel、CMS、G1、ZGC，个个都有自己的一套脾气。我自己最开始接触这些东西也有点发怵，后来踩了不少坑，把线上JVM参数翻来覆去调过好几轮，才慢慢理清楚了整个脉络。

这篇文章不打算给你敷衍地罗列那些官方定义。我把垃圾回收器这块内容拆成几个核心问题：它们到底在解决什么问题、各自的适用场景是什么、关键的参数怎么配、出了问题怎么排查。文章会结合我实际运维和调优项目的经历来讲，后面也会附上一些我整理的排查笔记。不管你是刚接触JVM的新手，还是已经写过不少GC调优参数的老手，我相信都能在里面找到点有价值的东西。

1. 垃圾回收器到底在解决什么问题

在聊具体回收器之前，先把最底层的问题说清楚。JVM的垃圾回收，本质上就做两件事：找出哪些对象已经死了，然后把它们占用的内存释放掉。看起来简单，但实际落地的时候，难点全在约束条件上。

1.1 为什么不能只靠引用计数法

先说说最简单的思路，给每个对象记一个被引用的次数，次数归零就回收。这个办法在教科书上一定出现过，但它解决不了循环引用的问题。两个对象互相引用，又没有其他入口指向它们，引用计数永远到不了0，就成了漏网之鱼，白白占着内存。

JVM主流实现采用的是可达性分析算法。思路比引用计数要聪明得多：从一组叫GC Roots的根对象出发，沿着引用链往下走，凡是走不到的对象，都被判定为可回收。这个GC Roots集合至少包含这几类：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（Java Native Interface）引用的对象

这里有个经验：面试和实际排查的时候，只要先判断“这个对象能不能从GC Roots走通”，就解决了一大半关于对象存活性的疑问。

1.2 分代假设是大多数回收器的地基

大部分垃圾回收器（ZGC里又不太一样）都默认接受一个经验法则：绝大多数对象存活时间极短，活下来的对象会活得更久。基于这个假设，堆被分成了新生代和老年代。

新生代又细分为Eden区、From Survivor区和To Survivor区。新对象通常进入Eden区，YGC（Young GC）之后还活着的对象会被挪到Survivor区。对象每熬过一次GC，年龄就加一，当年龄达到阈值（默认15，可调）时，就会晋升到老年代。

这么设计的好处非常明显：新生代的回收只扫局部区域，复制算法搬起来也快，能极大缩短停顿时间。老年代使用频率低，但内存大，适合用标记-清除或者标记-整理来处理。这正是垃圾回收器性能差异的底层来源。

1.3 GC停顿（Stop The World）是个绕不开的痛点

很多初学垃圾回收器的人，一看到Stop The World（STW）就发慌，以为是设计缺陷。实际上，为了保证在可达性分析过程中对象引用关系不能变，JVM不得不暂停所有业务线程。这不是什么无解的问题，而是“快照一致性”的代价。

你可以把STW理解为拍全家福之前喊大家站定，如果有人乱动，拍出来的照片就是对焦混乱的。垃圾回收器的发展史，基本就是跟STW做斗争的历史：有的回收器把停顿控制到几十毫秒以内，有的已经做到了停顿时间几乎可以忽略不计。

所以选择垃圾回收器，本质上就是在吞吐量、停顿时间、内存占用、实现复杂度这几个维度上做权衡。不存在万金油，只存在适不适合你的场景。

2. 常见垃圾回收器逐个拆解

2.1 Serial与Serial Old：单线程时代的老黄牛

Serial是最古老的回收器，新生代用的复制算法，GC线程只有一条。Serial Old则是老年代版本，用标记-整理算法。这两个组合在单核CPU或者客户端模式下还说得过去。

但放到现在的主流服务器环境下，Serial基本没有用武之地。除非你的应用是极小的独立进程，比如一个简单的工具类服务，堆内存就几百兆，并发数也不高，那Serial反而因为实现简单、没有线程切换开销，表现得还不错。

我给那种嵌入式的小型Java服务调优时，偶尔还会用Serial，不过绝大多数场景已经不会碰它了。如果你在一台多核服务器上给一个正经业务系统配了Serial，那你很快就会感受到什么叫长暂停。

2.2 Parallel Scavenge与Parallel Old：吞吐量优先的实干派

Parallel回收器大家应该不陌生，Java 8之前，它是服务端默认的新生代回收器。它的核心目标是达到一个可控制的吞吐量，吞吐量的定义是：运行用户代码的时间 / （运行用户代码的时间 + 垃圾回收时间）。

Parallel老年代版本用的也是标记-整理算法，两者的配合在Java 8这个版本上表现得中规中矩。适合什么场景？后台批量处理任务、离线计算、数据分析这类对响应速度不敏感、但对整体处理时间有要求的应用。

有一个参数组合很经典：

-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=4

ParallelGCThreads控制GC线程数，不是越多越好，一般跟物理CPU核心数差不多就行。我见过有人把线程数设得比CPU核数还多，结果GC线程之间频繁切换，停顿反而更严重。

2.3 CMS：低延迟的先行者，退役但并不罕见

CMS全称Concurrent Mark Sweep，是一款追求最短回收停顿时间的回收器，老年代使用标记-清除算法。它最大的特点是并发收集，在标记和清除阶段的大部分时间，GC线程可以和用户线程并发执行。

你依然会在很多存量系统里看到它的身影，因为Prometheus监控、业务响应峰值、以及某些支付网关的中间件，当年都用CMS配置。CMS也留下了一堆调优问题：

• 内存碎片化：标记-清除不压缩空间，时间长了老年代碎片多，分配大对象容易触发Full GC
• 并发模式失败：由于并发阶段用户线程还在跑，可能还没清完老年代就满了，退化回Serial Old做Full GC

CMS的经典参数配置大概长这样：

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection

CMSInitiatingOccupancyFraction一般设在60%到80%之间，意思是老年代用到这个比例时，提前触发CMS回收，别等满了再救火。UseCMSCompactAtFullCollection用于Full GC后做碎片整理，但代价是停顿时间变长，看你的业务能不能接受。

2.4 G1：区域化规划，默认已久的大当家

G1是Java 9及之后版本的服务端默认回收器，它把整个堆划分成一个个大小相等的Region区域，不再严格区分物理上的新生代和老年代，而是通过逻辑上的Region集合来动态划分。

G1的设计目标是用可预测的停顿时间模型，替代CMS。它维护了一个优先级列表，每次根据你设定的停顿时间目标，优先回收价值最大的Region，这就是G1名字里Garbage First的来源。

我做一个用户行为分析的在线服务时，从CMS切到G1的改动并不大，需要摸清楚的几个核心参数如下：

-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1HeapRegionSize=4m

MaxGCPauseMillis是期望停顿时间，注意它只是软目标，G1会尽量满足但不保证。G1HeapRegionSize可以设置Region的大小，如果对象都比较大，可以适当调大Region。G1里有不少新概念，比如Remembered Set（RSet）记录跨Region引用关系，再比如Humongous区域承载大对象，这些都是它比CMS复杂的地方，也是容易出现调优坑的地方。

2.5 ZGC：追求极致低停顿的先锋

ZGC的野心很大，目标是把停顿时间控制在10毫秒以内，而且这个目标不随堆大小增加而显著劣化。它采用了着色指针、读屏障、内存多重映射等一堆高级技术，做到了绝大部分回收过程与业务线程并发。

我跑过一个大堆实例（堆内存几百GB）的测试，ZGC的停顿时间确实能稳定在个位数毫秒级别。它适合那些堆超大、对延迟极端敏感的在线交易、实时推荐、量化回测等服务。但注意，ZGC的内存占用比G1要高，因为它需要额外的空间来支持并发整理和指针染色。配置也比较简单：

-XX:+UseZGC -XX:ZCollectionInterval=120

ZCollectionInterval是ZGC的回收间隔，可以按业务负载情况调整。别把它当银弹用，如果业务本身Full GC不被关心，那ZGC的优势就没那么大，还白白多吃了内存。

3. 回收器关键参数与选择思路

3.1 参数速查表

这里我整理了一份常用参数表，碰到不同场景直接查就好：

这张表我建议保存下来，排查问题的时候比翻官方文档快得多。

3.2 选型逻辑：别被新特性带着跑

很多人在选回收器的时候容易犯的错误，就是哪个新用哪个。ZGC听起来高大上，但如果你跑的是一个典型的Spring Boot接口服务，堆就4GB，QPS一千多，响应时间几十毫秒已经够快，那ZGC就是杀鸡用牛刀。

我个人的选型逻辑是这么一套判断流程：

1. 业务核心诉求是什么？是吞吐量还是低延迟？
2. 堆内存有多大？如果堆小于4GB，G1和Parallel差距不大，G1反而可能因为复杂度过高造成多余CPU消耗
3. 现有系统有没有历史包袱？老项目如果一直跑CMS且稳定，没必要为了“新默认值”强行迁移
4. 机器核数和内存大小？并发GC线程数、Region大小都要按实际硬件来
5. 出问题时能不能快速定位？配置越复杂，排查链路越长，团队技术储备要匹配

有个真实的教训：曾经接到一个数据同步项目，原团队把堆直接设成-Xmx64g，堆大阵营上选了G1，却忘了调整Region大小，结果大对象直接进了Humongous区域，频繁触发并发标记，响应时间直线上升。后来把G1HeapRegionSize从默认的1MB调到16MB，问题才算缓解。

4. 实操：一次完整的GC排查与调优记录

4.1 现象描述与基础数据收集

有一次要处理一个在线报价服务的频繁GC问题。服务的硬件环境是8核16GB，JVM参数大致如下：

-Xms4g -Xmx4g -Xmn2g -XX:+UseConcMarkSweepGC

线上日志里出现了大量的CMS remark停顿，单次停顿达到600毫秒以上，而且越来越频繁。业务响应时间被拖到3秒，已经影响到客户体验。

接手第一步，我先把GC日志给开了。注意，GC日志的配置在JDK 8和JDK 9以后有差异，当时是JDK 8，用的是：

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

如果是JDK 11+，推荐这么写：

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

JDK 9以后GC日志语法跟JDK 8完全不一样，网上很多文章都还是老的写法，使用前看清版本。

4.2 从GC日志里找线索

GC日志开头这一段是最有价值的：

[GC (CMS Initial Mark) [1 CMS-initial-mark: 2097152K(2097152K)] 2359873K(4015616K), 0.0012340 secs] [CMS-concurrent-mark-start] [CMS-concurrent-mark: 0.035/0.035 secs] [GC (CMS Final Remark) [YG occupancy: 927845 K (2097152 K)] 2765890K(4015616K), 0.6123450 secs]

看到没，Initial Mark只有1毫秒多，concurrent mark也就35毫秒，这个都正常。问题出在Final Remark：0.6秒，这个停顿长得离谱。但remark阶段要做的是重新标记并发阶段变化了的对象，通常也就是几十毫秒的事，怎么拖到600毫秒？

原因往往是新生代对象太多，remark找根的时候要扫描新生代，花了很多时间。这个场景的瓶颈其实在新生代，而不在老年代。我当时的思路就是给CMS的remark减负。

CMS在remark时会暂停所有业务线程，所以它扫描的根集合越小越快。可以配置：

-XX:+CMSParallelRemarkEnabled

这个参数把remark阶段变成多线程并行，能显著缩短停顿。另一个思路是增加新生代空间，让对象别那么快晋升到老年代，同时减少Survivor区的复制压力，把-Xmn从2g调到3g。

但这里有个平衡问题，老年代只剩1g，会不会更早触发Full GC？当时用jstat看了一眼老年代使用率，只有40%左右，还有不少余量，所以这个调整是可以接受的。调整后的参数：

-Xms5g -Xmx5g -Xmn3g -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=75

调完之后，CMS remark停顿从600毫秒降到了80毫秒左右，服务响应时间回到几百毫秒内。这个案例想表达的核心是：GC调优第一件事不是去Google“哪个参数最牛”，而是先看清日志里最长的停顿发生在哪一阶段，然后顺着这个阶段找原因。

4.3 用工具辅助判断堆内存分布

日志毕竟只反映结果，要看堆里到底是什么对象占着空间，必须用堆快照分析工具。OOM和内存泄漏排查，我是这样做的：

• 第一步，JVM参数里提前打开HeapDumpOnOutOfMemoryError和HeapDumpPath，避免OOM发生后再去复盘，连现场都没有
• 第二步，用jmap生成当前堆转储快照，命令是：

jmap -dump:live,format=b,file=/data/dumps/heap.hprof <pid>

这个命令只dump存活对象，适合排查生产环境，避免文件太大

• 第三步，用MAT（Memory Analyzer Tool）或VisualVM打开快照，重点看“Leak Suspects”或者“Dominator Tree”，定位大对象和引用链

我碰到过一个奇怪的内存增长问题，堆总是涨着涨着就Full GC。后来dump完一看，有个全局静态Map里缓存了大量业务数据，没有做容量限制和过期清理，时间长了自然撑爆老年代。这种情况GC参数帮不上忙，只能改代码。

调优切忌上来就调参数，先看看是不是代码本身就藏了问题。

5. 疑难问题排查与独门排查顺序

到了这一部分，说一下真正在实战里能用到的排查流程。我之前把排查步骤固定下来，每次出GC问题，按这个顺序走，省掉很多瞎猜的时间。

5.1 排查问题的五步顺序

第一步，看监控指标。先把Full GC次数、停顿时间、吞吐量这些指标捞出来，确认问题到底严重与否。很多人一遇到CPU飙高就怀疑GC，实际看下来可能只是业务代码死循环。

第二步，看GC日志。按时间范围把日志拉出来，确认是YGC频繁还是Full GC频繁，停顿具体是哪一阶段。这里有个观察重点：如果YGC后老年代使用率突然涨了一大截，说明晋升对象年龄阈值太低，或者Survivor区太小，对象来不及在新生代被回收就被推去老年代。

第三步，看堆内存分配。用jstat -gcutil看各个区域的使用率，确认新生代Eden、Survivor、老年代各自处于什么水位。通常规律是：Eden频繁打满导致YGC频繁，老年代持续缓慢上涨直到触发Full GC。

第四步，看对象来源。当老年代稳定上涨、Full GC也拦不住的时候，必须dump堆，用MAT排查到底是谁在引用这些存活对象，是缓存、是连接池、还是某个集合没清理。

第五步，综合判断到底是调参、还是改代码、还是加内存。这三类手段要同时考虑，而不是只盯着参数看。

5.2 常见问题对照速查表

5.3 最容易忽略的两个细节

第一个是jstat与GC日志时间点对不上。jstat是采样式工具，它输出的是采样时刻的实时状态，而GC日志记录的是事件发生的时间点，两者之间本来就有时间错位。排查问题时一定要以GC日志为准，jstat只用来做趋势判断。

第二个是CMS并发模式失败。当并发回收还没做完，老年代就被新对象占满时，JVM会退化到Serial Old做Full GC。这种Full GC是单线程的，停顿时间往往是秒级。看到日志里出现concurrent mode failure，就是提醒你CMSInitiatingOccupancyFraction设得太高，或者老年代空间确实不够了。

ZGC和G1虽然解决了大部分CMS的问题，但同样不是没有自己的坑。G1的Humongous分配处理不好会触发连续Full GC，ZGC对内存占用要求更高，部署时必须给JVM进程多留物理内存来配合它的并发整理。

6. 多种场景下的配置参考

下面整理几套我实践下来相对稳妥的配置模板，按场景划分，可以直接作为起点，再根据压测结果微调。

6.1 标准Spring Boot微服务

这种服务通常堆不大，要求稳定响应，不要有大停顿。推荐G1：

-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1HeapRegionSize=4m \ -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/heap.hprof

为什么区分Region为4m？因为如果服务内部偶尔会创建几百KB到几MB的数组，默认1MB的Region会导致这些对象直接视为Humongous，触发额外的GC压力。4MB是对大多数常规互联网服务比较均衡的配置。

6.2 高并发低延迟交易类服务

这个场景，响应时间优先，堆也不能太小，可以直接上ZGC。但前提是物理内存要够，16GB内存的机器跑-Xmx6g已经比较勉强，ZGC建议至少留一半内存给它做回收缓冲。大致配置：

-Xms8g -Xmx8g -XX:+UseZGC -XX:ZCollectionInterval=60 -XX:+HeapDumpOnOutOfMemoryError

6.3 离线批处理与计算密集任务

这类服务不关心单次响应，只关心每小时能处理多少数据。首要目标是吞吐量最大化，选Parallel组合最合适：

-Xms10g -Xmx10g -XX:+UseParallelGC -XX:ParallelGCThreads=8

Parallel的吞吐量表现往往比G1更好，因为它不需要维护RSet这类额外结构，CPU开销更少。这一点不少人容易忽略：G1虽然新，但并不是所有场景都比Parallel快。

6.4 容器环境下的特别注意事项

容器化部署已经是常态，但JVM在容器里的表现有个经典问题：默认情况下，JVM识别的是宿主机CPU核数和内存，而不是容器限制的资源。如果你给容器设了2核4GB，JVM却以为自己跑在32核128GB上，然后按宿主机规格去分配GC线程和堆，结果就是各种折腾。

现在主流JDK已经默认开启UseContainerSupport，能够识别容器限制。但老一点的JDK 8版本，可能需要显式加两个参数：

-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0

MaxRAMPercentage表示JVM最大堆占容器内存的比例，75%是一个相对平衡的选择。千万别把MaxRAMPercentage设到90%，因为堆外还有Metaspace、线程栈、JIT编译缓存，这些都要吃内存，全占了会导致整机内存吃紧。

容器场景下最忌讳的是给-Xmx设一个固定值，却忽视了容器本身内存限额的变化。比如容器原来限额4GB，后来扩到8GB，如果你写死-Xmx4g，就白白浪费了扩出来的内存。用百分比配合容器配额，运维自己调整限额就够了，不用改应用配置。

这里有个坑我要多提一嘴：容器化以后，很多人看内存指标只盯着JVM堆，却忽略了堆外内存。像Netty这样的框架，大量使用堆外缓冲区（Direct Memory），还有线程栈、Metaspace，这些都不受-Xmx管理。一旦堆外内存溢出，监控上看堆还剩一大半，进程却报OutOfMemoryError，排查难度直接上升。碰到这种情况，建议加上：

-XX:MaxDirectMemorySize=1g

给Direct Memory设个上限，别让堆外部分无限增长。

7. 工具与调优实践的一点经验

工欲善其事，必先利其器。排查GC问题，我常用的工具就那几个，但每个都有自己的擅长场景。

7.1 常用工具清单及定位

第一条是jstat，命令行下jstat -gcutil 1000，每1秒采样一次，看Eden、Survivor、老年代的使用率和GC次数。它在快速判断“当前GC是否频繁”上最快最直接。

第二条是jmap，用于导出堆快照，配合MAT做对象引用分析。jmap执行时会把进程短暂停顿一下，生产环境使用要谨慎，尽量低峰期执行，或者用jhsdb替代（JDK 9以后的替代品）。

第三条是jvisualvm和VisualGC插件，适合在本机或者测试环境看JVM实时曲线，直观，但不建议在生产环境开远程连接，性能开销大。

第四条是MAT，分析hprof文件必备，它的Leak Suspects报告和Dominator Tree几乎是定位内存泄漏的标配。

7.2 调优时一个被反复验证的准则

没有压测就没有调优。线上出了问题当然要处理，但更理想的做法是上线之前就通过压测把配置验证好。我用压测一般会这样安排：先按经验设置一组参数，然后在性能测试环境跑一轮并发压测，观察各项指标，再调整参数，再跑一轮，直到压测结果符合预期。压测场景要贴近线上真实流量，不能只压接口吞吐量，要压出不同时间长度的峰值流量，看GC频率和停顿是否稳定。

曾经有个项目，测试环境怎么压都正常，一上生产就出现周期性的Full GC。后来把线上流量数据拿回来一分析，才发现是夜间的一个定时批量任务，会一次性构造大量庞大对象，直接把老年代打满。压测脚本没有覆盖这个批量场景，等于漏掉了核心风险点。从那以后，我给项目做GC验证时，都会要求把定时任务、批量任务全部纳入压测范围。

7.3 参数调整的一次完整复盘

我自己做过的比较典型的一次调优案例，是一个用户积分服务。初始配置用的是JDK 8默认的Parallel：

-Xms6g -Xmx6g -XX:+UseParallelGC

压测时发现，并发到800时，YGC平均间隔只有1秒，单次YGC耗时约80毫秒，还能接受。但当并发到1200时，YGC间隔缩短到300毫秒，单次耗时飙到200毫秒以上，接口P99延迟直接到了1800毫秒。

当时的判断是：新生代可能太小，导致频繁YGC；YGC耗时变长又可能是Survivor区复制压力太大或者晋升对象过多。于是采取两步调整：

第一步，扩大新生代，通过NewRatio和SurvivorRatio调配：

-Xms8g -Xmx8g -Xmn4g -XX:NewRatio=1 -XX:SurvivorRatio=6

第二步，换成G1，并把停顿目标设为50毫秒：

-XX:+UseG1GC -XX:MaxGCPauseMillis=50

对比之后发现，Parallel在吞吐量上仍然略有优势，但G1在P99延迟上表现更好。当时的业务实时性要求高，最终选择了G1。后来在服务冷启动阶段，又发现G1的RSet维护CPU开销偏高，于是加上了Region大小的调整，把G1HeapRegionSize调成了8MB。这个调整让大对象的分配不再走Humongous通道。

最终配置大概是：

-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=8m

压测结果：并发1200时，单次YGC停顿降到30毫秒左右，P99延迟控制在600毫秒上下，达到了预期。

这个案例里，每一步参数选择都有明确理由，不是为了调而调。如果你也碰到了类似困扰，建议就按这个思路来：先明确性能指标，再压测暴露问题，然后针对性地调参数，最后用压测数据验证结果。

8. 直观对比：不同回收器该怎么选

最后把这个选型的逻辑再串一遍。很多人手里拿着几款回收器，却不知道什么场景该选谁。我从实际使用的角度，做了一张对比表：

有些细节，表格里体现不出来，单独说一说：

Parallel的吞吐量优势，是在并发量不高、堆空间充足的情况下才明显。如果你的服务是低延迟敏感型，建议优先考虑G1或者ZGC。CMS的延迟低，但不稳定，尤其老年代碎片化以后，延迟会突然飙升，这是它被G1逐渐取代的核心原因。G1的默认停顿目标其实是200毫秒，很多场景可能不需要进一步调低，你要是强行调到50毫秒，反而可能导致GC频率上升，吞吐量下降。ZGC的内存占用通常比G1多10%到20%，物理内存不富裕时要慎重。

关于垃圾回收器，其实真的不用太焦虑选型问题。JVM默认的回收器是经过了大量工程验证的，在没有特殊需求的情况下，直接用默认就是很可靠的选择。真正需要你深入理解回收器底层逻辑的，是线上出现了非正常GC行为、响应时间恶化、内存水位持续偏高等异常情况时。到那一刻，本文前面讲的这些参数、排查顺序、工具使用方式，才是帮助你快速定位和解决问题的关键。

我个人在实际使用中的体会是：垃圾回收器调优，很多时候不是越调越多，而是越调越简。删掉没必要的参数，守住核心停顿目标和内存水位，剩下的让JVM自己判断，反而比一股脑堆参数要稳得多。