企业官网建设流程全解析

1. 先搞清楚调优的方向：GC日志到底能告诉你什么

1.1 调优之前必须建立的三个基本认知

先说结论：JVM调优最核心的输入就是GC日志。没有日志支撑，所有的参数调整都是盲猜，调对了是运气，调错了是常态。我见过太多人上来就改堆大小、换垃圾收集器，结果线上 gc 频率没降多少，反而把停顿时间拖长了。要避免这种情况，你必须先建立三个基本认知。

第一个认知：GC日志不是性能报告，而是事件流水账。每一行GC日志只记录一次垃圾回收事件，它告诉你"什么时候发生了回收、回收了多少内存、用了多长时间"。这些零散的事件拼合起来，才能还原出JVM内存使用的真实面貌——比如老年代在什么业务时段持续增长、新生代对象晋升速率有多快、Full GC是不是伴随着某个接口的调用峰值。所以分析日志的第一步，永远是把零散记录聚合成趋势，而不是盯着一两条日志死磕。

第二个认知：参数优化是决策，不是照抄配置。网上流传的各种"最佳实践''参数模板，本质上是在一个特定场景下验证过的结果，换到你的业务模型里可能完全失效。比如一个以读为主、对象朝生夕灭的Web服务，和一个处理大文件、批量任务的数据管道，两者的内存分配模型截然不同，适合的 GC 参数也必然不一样。你要做的是理解每个参数背后的权衡逻辑，然后根据自己日志里暴露的痛点是频率高、停顿长还是吞吐低，去选择对应的调整方向。

第三个认知：调优靠数据说话，不靠直觉。不管是判断"要调大新生代"还是"该换G1"，每一条决策都必须有日志数据支撑：对象晋升速率是多少？Survivor区有没有频繁溢出？每次GC的平均耗时和中位数是多少？这些指标才是指挥棒。后面我会拿出一套完整的实操流程，演示怎么从日志数据一步步推导出该改哪个参数。

1.2 常见垃圾收集器的工作特性与选型判断

GC日志格式和使用方式，跟JVM当前用的收集器强相关。在看日志之前，你得先确认自己的JVM用的是什么收集器。这里我按使用频率从高到低讲一下主流收集器的日志差异。

• Parallel Scavenge / Parallel Old：JDK 8 的默认组合，关注吞吐量。它的新生代日志格式是 "PSYoungGen"，支持使用 -XX:+UseParallelGC 主动启用。
• Serial单线程收集器：日志格式是 "DefNew"，常见于客户端模式或小堆场景。
• ParNew + CMS：JDK 8 时代互联网公司很常见的组合，日志格式是 "ParNew"（年轻代）+ "CMS"（老年代）。它的日志里特别值得关注的是 "CMS-initial-mark"、"CMS-concurrent-mark" 和 "CMS-concurrent-abortable-preclean" 这几个阶段，任何 concurrent mode failure 都意味着老年代回收跟不上对象分配速度。
• G1：JDK 9+ 的默认收集器，日志以 "garbage-first heap" 或 "G1 Evacuation Pause" 开头。它的调优维度和传统分代收集器差异很大，重点看 Mixed GC、Region 分配和 Humongous 对象。
• ZGC：超低停顿方向，日志以 "ZGC" 开头，关注的是 ZGC 各阶段的并发时间占比，一般用于超大堆场景。

从日志识别当前收集器是最快的路径：启动时加 -XX:+PrintGCDetails，然后看GC日志第一行跟哪个名字能对上。这个信息决定了你后续哪些参数有意义。比如你在 G1 上调整 -XX:NewRatio，它虽然认这个参数，但实际效果远不如调 -XX:G1NewSizePercent 来得直接。在 Parallel 上设置 -XX:G1HeapRegionSize 则完全无效，因为那个参数只对 G1 生效。

所以我的习惯是：拿到一个线上JVM，第一步永远是拿到启动参数，确认收集器版本和关键配置，第二步才是找一段覆盖业务峰值时段的GC日志做分析。顺序不能反，否则分析半天可能是在给错误的收集器对症下药。

2. 读懂GC日志：从格式到含义的完整拆解

2.1 一次Young GC日志逐行解读

现在拿一条平行收集器的典型Young GC日志来做拆解。启动参数是 -XX:+PrintGCDetails 时输出的就是这种格式：

[GC (Allocation Failure) [PSYoungGen: 61440K->8928K(61440K)] 61440K->12032K(197632K), 0.0215876 secs] [Times: user=0.04 sys=0.01, real=0.02 secs]

拆开来看：

• GC：表示这是一次Minor GC。如果是Full GC，说明老年代或元空间也参与了回收。
• (Allocation Failure)：触发原因，说明是新生代分配对象时内存不足。这是最常见的触发因素，意味着年轻代已经填满了。
• PSYoungGen：新生代回收前后存量，格式是回收前大小->回收后大小(该区域总大小)。61440K->8928K(61440K)：GC前用了60MB，回收后剩8.7MB，但总容量还是60MB。回收后没到0，说明有部分对象存活。
• 61440K->12032K(197632K)：整个堆的回收前后和总大小。整堆从60MB降到11.7MB，总大小是193MB。这里要注意，堆总大小是新生代容量+老年代容量，但不同收集器对Survivor区的口径有差异。
• 0.0215 secs：STW停顿时间，这是小停顿的核心指标。0.02秒的停顿对大部分业务可以接受，但如果这个值持续超过0.2秒就要警觉了。
• Times：user是用户态CPU时间、sys是内核态CPU时间、real是真实耗时。多线程回收时 real往往远小于 user，因为回收工作被多个GC线程并行执行了。如果 user/sys 很低而 real 很高，多半有CPU竞争或IO抖动。

再看一条G1的日志，格式差异就比较明显：

[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0236124 secs] [Parallel Time: 21.0 ms, GC Workers: 8] [Eden: 56.0M(56.0M)->0.0B(44.0M) Survivors: 8192.0K->12.0M Heap: 64.0M->18.0M(256.0M)]

G1关注的字段是Eden 区收缩量、Survivor 区变动和整堆回收前后的变化。如果你在日志里频繁看到Humongous Allocation或G1 Humongous Allocation，说明有大对象（超过Region一半大小）频繁分配，这在大对象扎堆的场景下很致命。

2.2 Full GC日志特征与危险信号

Full GC的日志与Young GC差异明显，重点表现在"整个堆都参与了回收"：

[Full GC (Metadata GC Threshold) [PSYoungGen: 8192K->0K(9216K)] [ParOldGen: 255M->190M(256M)] 263M->190M(265M), [Metaspace: 127M->127M(128M)], 0.5138210 secs]

这条日志里有几个危险信号：

• 元空间触发 Full GC，Metaspace 从127M塞到127M，总大小128M。这种情况在动态生成类的应用里很常见，解决方向是调大 -XX:MaxMetaspaceSize，或者排查是不是类加载器泄漏。
• 老年代从255M降到190M，回收后仍占用74%，这说明老年代中存活对象比例高，新生代晋升过来的对象密度大。
• 耗时0.5秒，这已经是明显影响线上接口RT的水平。如果 Full GC 持续超过1秒，说明堆内存压力已经到临界点。

另一个高频危险信号是CMS 的 concurrent mode failure：

[GC (Allocation Failure) [ParNew: 6144K->6144K(6144K), 0.0123456 secs][CMS: 10240K->10000K(10240K), 0.5433212 secs]

看到 ParNew 回收后数量没变（6144K->6144K），紧接着 CMS 又用了0.54秒做老年代回收，这就是 CMS 并发回收跟不上新生代晋升速率的结果。遇到这种情况，光调新生代大小没意义，得考虑给老年代留更大空间或者降低晋升速率（比如调大 Survivor 比例），甚至考虑换 G1。

2.3 利用jstat实时查看GC状态

GC日志是事后分析，但很多线上排查场景需要即时数据。jstat 是我最少不了的命令，没有之一：

jstat -gcutil 12345 1000 20

这个命令每秒输出一次进程12345的GC利用率，共输出20次。输出的S0、S1、E、O、M分别代表两个Survivor区、Eden区、老年代和元空间的使用占比，YGC和FGC是累计回收次数，GCT是累计回收总耗时。

我常用的排查套路是：先执行上面这条看当前各区占比和GC频率，再叠加业务的请求量指标。如果发现老年代占比从20%一路涨到80%且不回落，就算 YGC 次数不多，也基本可以确认有对象在持续进入老年代，下一步才需要 dump 堆找是谁的问题。jstat 输出的最大优势是实时无侵入，线上直接敲命令就能看，不像 JFR 需要录制和分析，适合做快速判断。

3. 参数优化的核心逻辑：从日志数据反推参数

3.1 用日志指标反推优化方向

日志读懂了，参数优化就有了依据。优化的本质其实是围绕三个目标的平衡：低停顿、高吞吐、低内存占用，这三者在绝大多数场景下不可兼得。我的判断框架是这样的：

• 如果GC频率过高（Young GC每秒好几次），但单次停顿很短，说明堆太小或者新生代太小，可以考虑整体调大堆。
• 如果单次停顿过长，说明单次回收的对象量太大，需要缩小单次回收规模，比如调小新生代、增大 Survivor、或者换并发收集器。
• 如果Full GC 频率高，优先排查内存泄漏和对象晋升，而不是急着加内存。
• 如果吞吐量不达标（GC总耗时占业务运行时间比例过高），优先考虑大堆 + Parallel 模式，它天生为吞吐优化。

举个具体的计算例子，假设日志里统计出：1小时内发生了120次Young GC，每次平均耗时0.02秒，同时有2次Full GC，每次平均耗时0.5秒。那么 GC 总耗时是 120×0.02 + 2×0.5 = 2.4 + 1.0 = 3.4秒，占整小时的0.094%。从吞吐角度看，99.9%的算力都花在业务上，这种情况完全不需要调优。但如果你的业务的P999耗时因为那两次1秒的Full GC而从80ms涨到1.2秒，那问题就是停顿而不是吞吐。

有一个我常用的经验值：线上服务的 Young GC 频率控制在每10秒一次以内、单次停顿低于50ms，Full GC 一天不超过几次且单次不超过200ms，基本就不需要过多干预。超出这个范围，再动手不迟。

3.2 关键参数作用与计算示例

这里把高频使用的参数整理成速查表：

给一个具体的计算过程。线上服务堆内存定为4GB，日志显示 Young GC 每5分钟一次，老年代占比却缓慢上升。我把 -XX:NewRatio 从默认的2调成3之后，新生代从约1.33GB降到1GB，老年代从2.67GB升到3GB。表面上看新生代小了应该更频繁GC，但由于老年代多了空间，Full GC 被推迟了。这就是典型的用老年代的余量换取 Full GC 的频次下降。

再看 Survivor 区调整。默认 Eden:Survivor = 8:1:1，假设新生代1GB，Eden约819MB，每个Survivor约102MB。如果日志里出现大量对象从Survivor晋升到老年代（在Full GC日志里看到老年代增长曲线陡峭），说明存活对象超过Survivor的容量。把 SurvivorRatio 调成6，Eden降到768MB，Survivor升到128MB，晋升少了，Full GC 自然也少了。这种微观调整对降低 Full GC 频率效果显著。

3.3 不同场景的参数配置模板

不同业务模型的参数模板差异很大，我按场景给出三套常用模板，供你在此基础上根据实际日志微调。

Web服务（吞吐优先，响应延迟敏感）4-8GB堆，JDK8 + Parallel：

-Xms4g -Xmx4g -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log

大堆服务（16GB+堆，追求可控停顿）JDK11+，G1：

-Xms16g -Xmx16g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60 -XX:+PrintGCDetails -XX:+PrintGCDateStamps

低延迟网关/中间件（追求低停顿）JDK17+，ZGC：

-Xms8g -Xmx8g -XX:+UseZGC -XX:ZCollectionInterval=2

这三套模板的核心差异在于：Parallel 用频繁但快速的新生代回收换吞吐，G1 用可预测的停顿模型换平滑的延迟表现，ZGC 用并发回收把停顿压到毫秒级。搞清楚你的业务更怕哪种性能劣化，再选对应的模板，比直接抄参数靠谱得多。

4. 完整实操：一次JVM调优的现场记录

4.1 问题描述与初步排查

有一次帮朋友排查他们的订单服务：业务高峰期接口P99耗时从80ms飙到900ms，链路追踪里看到大量请求卡在服务内部，但数据库响应正常。初步怀疑JVM停顿，立刻拿 jstat 看实时状态，发现老年代利用率已经到92%，且频率很高。于是拉取当时的GC日志，缩小排查范围：

2019-08-12T10:24:31.209+0800: 3721.456: [GC (Allocation Failure) [PSYoungGen: 61440K->6272K(61440K)] 61440K->34832K(197632K), 0.0256112 secs] [Times: user=0.05 sys=0.01, real=0.03 secs]

Young GC后整堆依旧占用34MB，老年代持续增长。10秒后出现Full GC：

2019-08-12T10:24:41.772+0800: 3731.019: [Full GC (Ergonomics) [PSYoungGen: 6144K->0K(61440K)] [ParOldGen: 196608K->130048K(197632K)] 202752K->130048K(197632K), [Metaspace: 10240K->10240K(10240K)], 0.5321871 secs]

Full GC 耗时0.53秒，老年代回收后仍有130MB，占比高达66%。这说明问题不在JVM参数本身，而是有大量对象在持续进入老年代且无法释放。

4.2 日志深度分析与定位过程

把 GC 日志导入 GCViewer，统计一个小时内的数据：Young GC 平均每40秒一次，耗时稳定在20ms；Full GC 每20分钟一次，耗时500ms。Full GC 频率远高于健康水位。

再用 jmap 做堆转储：

jmap -dump:format=b,file=heap.bin 12345

用 Eclipse MAT 分析后，发现一个订单缓存 Map 对象占据了堆内存的42%。根因是缓存系统在高峰时段对订单状态做了全量拉取但缺少过期机制，大量订单状态对象无法被GC回收。这一步是重点：参数调优不能解决代码层面的对象生命周期管理问题。参数再合理，对象还在那里堆着，老年代还是会涨满。遇到这种情况，先把代码逻辑修正，再回头评估JVM参数是否需要动。

4.3 参数调整与效果对比

代码修正后，我做了如下参数调整，目标是扩大新生代以容纳更多短期对象、降低 Young GC 频率：

• 堆大小从 192MB 提升到 512MB（-Xms512m -Xmx512m），该服务是轻量级订单服务，512MB 足够承载峰值流量；
• 保持 NewRatio=2，使新生代约170MB；
• SurvivorRatio 从8调成6，加大Survivor容量，降低晋升；
• 开启 HeapDumpOnOutOfMemoryError，为后续兜底。

调整前后效果对比如下：

调完参数后持续观察一周，Full GC 频率没有再回升，P99 稳定在100ms左右。这次调优总结下来，80%的收益来自代码修复，20%来自参数优化。参数优化是放大器，方向对了它放大效果，方向错了它放大故障。

5. 常见问题与排查技巧实录

5.1 高频故障场景速查表

实际工作中，线上 JVM 问题基本跑不出下面这几类。我做了一个速查表，排查时先对照确认方向：

每个方向背后都是独立的排查链路，这里不再展开，但有一句话值得强调：凡是遇到参数调优解决不了的内存问题，先回到代码层面找对象生命周期管理的问题。JVM调优的首选策略永远是"少制造垃圾"，其次才是"把垃圾收拾得更快"。前者靠代码，后者靠参数。

5.2 踩过的坑和避坑心得

第一个坑：生产环境忘了加 -XX:+PrintGCDateStamps。默认的GC日志时间是很不友好的相对时间戳（3731.019这样的JVM启动秒数），要把这个数字对应到业务具体的时刻，得先换算启动时间，非常痛苦。后来我把这个参数列入了新项目启动模板的必选项，还加了 -XX:+PrintGCDetails，没有这两个参数就不要谈后续分析。

第二个坑：调了 -Xmx 忘了调 -Xms。JVM运行中从初始堆向最大堆扩容是需要开销的，扩容过程本身就伴随STW，这在堆从512MB往4GB扩张的场景下表现特别明显。生产环境一定把两个值设成一致，宁可初始就大一些，不要让JVM在运行中频繁扩缩容。

第三个坑：GCViewer 导出的数据不是越多越好。刚接触GC日志的人喜欢统计所有时间段的数据，结果把一次发布带来的日志混进了一天的数据里，GC频率被平均得毫无参考价值。分析前先按业务发布节点切割时间窗口，只分析某个稳定运行时段的数据。我习惯看"峰值时段单独一段、全量时段单独一段"，否则平均值会掩盖真实问题。

第四个坑：只看平均值，不看P99。有一次调完参之后，GC平均停顿从100ms降到了60ms，看起来很成功。后来一细看分位数才吓一跳，P99停顿有700ms。平均值的欺骗性就在这，GC日志分析一定要看分布，至少拆出P50、P90、P99。

5.3 常用工具链推荐

最后整理一下我常用的工具清单，给入手JVM调优的朋友一些参考：

• jstat：JDK自带，适合快速查看实时GC状态，零侵入。
• jmap：堆转储和查看堆配置的标准工具，注意在堆内存紧张的时候执行会加大压力，线下场景可以用 jhsdb 替代。
• GCViewer：开源的GC日志图形化分析工具，适合看趋势，统计粒度和图表都很方便。新版建议直接用在线版的 gceasy.io，图表交互更友好，但注意日志上传前脱敏。
• Eclipse MAT：堆转储分析利器，能直接给出最大对象的保留链，内存泄漏定位用它效率最高。
• JFR + JMC：JDK 11+ 的飞行记录器。比起GC日志，它能额外看到线程、IO、锁等更多维度，当你怀疑问题不在GC而在应用自身时，就用它做全维度诊断。

工具终归是辅助，底层逻辑才是核心：先确认目标（低停顿还是高吞吐），再计算偏差（现在离目标差多少），最后动参数（用日志验证效果）。

写在最后

从最早被线上突发Full GC搞得焦头烂额，到现在能相对从容地通过日志定位问题，我个人的体会是：JVM调优没有什么神秘的高深理论，它更像一门门槛不高的手艺活。只要肯花时间把日志格式吃透、把每个参数背后的权衡想明白、再积累几轮"调整后观察-记录-再调整"的实战循环，大部分业务场景的性能瓶颈都能被有效控制。

如果只让我留一个建议，那就是：每次调整只改一个参数，改完用日志验证，对比前后趋势，再动下一个。很多人喜欢一次性给JVM换血式地调五六个参数，出了问题根本分不清是谁的锅。一次只改一个，虽然看起来慢，反而是最快的路径。

这轮分享就到这里。希望下次你再看GC日志的时候，每一行都像读电报一样清晰。如果这篇文章帮你少走了一个坑，那它就值了。