摘要凌晨三点告警响起“订单服务 Full GC 次数异常”。登录服务器一看Full GC 每隔 3 分钟就触发一次每次停顿 3 秒以上用户下单开始超时。本案例从 GC 日志分析入手定位出老年代持续增长的根本原因——大量短生命周期对象因 Survivor 太小而被过早晋升。通过调整 SurvivorRatio 和晋升阈值配合代码层面的对象池优化将 Full GC 频率从每 3 分钟降到每 8 小时运行稳定至今。一、问题背景1.1 业务场景某电商平台的订单服务部署在 4 核 8GB 的物理机上运行 JDK 8u302使用 G1 GC。正常情况下 QPS 约 2000大促期间峰值 15000。1.2 故障现象告警信息 [2026-03-15 03:00:00] Full GC 次数超过阈值当前 15次/小时阈值 5次/小时 [2026-03-15 03:05:00] 接口 TP99 响应时间 5s正常 200ms [2026-03-15 03:08:00] 服务开始拒绝请求连接池耗尽 运维操作 1. 重启服务 → 临时恢复 2. 30 分钟后再次出现同样问题 3. 陷入重启循环1.3 原始配置# 发现问题时的 JVM 配置-server-Xms8g-Xmx8g-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:NewRatio2# 年轻代 2.7GB老年代 5.3GB-XX:SurvivorRatio8# Survivor 各 300MB极小-XX:MetaspaceSize256m -Xlog:gc*:file/var/log/gc.log-XX:HeapDumpOnOutOfMemoryError二、问题分析2.1 GC 日志分析# Full GC 日志片段 2026-03-15T03:00:00.1230800: 12345.678: [Full GC (Allocation Failure) [GC pause (G1 Evacuation Pause) (young) (to-space overflow) ... [Root Region Scan Waiting: 0.0 ms] [Code Root Fixup: 0.1 ms] [Clear CT: 0.2 ms] [Other: 123.4 ms] 4567.8 ms]# 关键指标提取 # 从日志中提取的 GC 统计 # - Minor GC 频率每 15 秒一次 # - Minor GC 回收量约 800MB # - 晋升到老年代的对象量约 500MB/次 # - 老年代从 3GB 增长到 5.3GB 只需约 3GB / 500MB * 15s 90s但实际是 3 分钟 # → 问题Minor GC 频率低但晋升量大说明 Survivor 太小2.2 jstat 验证# 在问题发生时执行 jstat$ jstat-gcutil12345100010# 输出取最后一行# S0 S1 E O M YGC YGCT FGC FGCT GCT# 98.50 0.00 85.00 95.50 82.30 245 45.67 189 234.56 280.23# 解读# S0 98.5% → Survivor 0 几乎满了# O 95.5% → 老年代使用率 95.5%接近 OOM# FGC 189 → Full GC 已经发生 189 次# FGCT 234s → Full GC 总耗时 234 秒约 1.2 秒/次2.3 jmap 堆直方图# 堆直方图分析$ jcmd12345GC.class_histogram|head-30# 占用最大的对象类型# num #instances #bytes class name# 1 1234567 98765432 [Ljava.lang.Object; (对象数组)# 2 234567 45678901 com.example.OrderItem# 3 123456 34567890 com.example.Order# 4 89012 23456789 java.lang.String# 5 45678 12345678 java.util.HashMap$Node# 分析# - 约 230 万个 OrderItem 对象存在# - 每个 OrderItem 约 200 字节# - 这些对象应该被 Minor GC 回收但大量晋升到老年代2.4 根因定位┌──────────────────────────────────────────────────────────────────┐ │ 问题根因分析 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ SurvivorRatio8 意味着 │ │ 年轻代 2.7GB Eden(2.4GB) Survivor0(0.15GB) Survivor1(0.15GB) │ │ │ │ 问题链条 │ │ 1. 订单处理高峰期每 15 秒 Minor GC │ │ 2. Minor GC 后约 500MB 对象存活 │ │ 3. Survivor 只能容纳 150MB → 350MB 对象溢出 → 直接晋升 │ │ 4. 350MB/次 * 4次/分钟 * 3分钟 4.2GB → 老年代快速填满 │ │ 5. 老年代达到阈值 → Full GC每 3 分钟一次 │ │ │ │ 根因Survivor 太小 晋升阈值默认动态调整偏低 │ │ │ └──────────────────────────────────────────────────────────────────┘三、解决方案3.1 方案一紧急止血JVM 参数调整# 调整后的 JVM 配置-server-Xms8g-Xmx8g-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:NewRatio2# 保持-XX:SurvivorRatio4# 调整300MB → 600MB扩大一倍-XX:MaxTenuringThreshold15# 调整提高晋升阈值-XX:TargetSurvivorRatio90# 新增Survivor 使用率目标-XX:MetaspaceSize256m -Xlog:gc*:file/var/log/gc.log-XX:HeapDumpOnOutOfMemoryError3.2 方案二代码层面优化// 问题代码大量临时对象publicListOrderItembuildOrderItems(ListProductproducts){ListOrderItemitemsnewArrayList();// 每次调用都 newfor(Productp:products){OrderItemitemnewOrderItem();// 每次都 newitem.setProductId(p.getId());item.setPrice(p.getPrice());item.setQuantity(1);items.add(item);}returnitems;}// 优化方案 1对象池复用publicclassOrderItemPool{privatestaticfinalConcurrentLinkedQueueOrderItemPOOLnewConcurrentLinkedQueue();publicstaticOrderItemborrow(){OrderItemitemPOOL.poll();returnitem!null?item:newOrderItem();}publicstaticvoidreturnObject(OrderItemitem){item.clear();// 重置字段POOL.offer(item);}}// 优化方案 2批量处理减少中间对象publicvoidprocessOrdersBatch(ListOrderorders){// 在数据库层批量操作减少 Java 对象创建orderRepository.saveAll(orders);}3.3 调优参数计算新配置的 Survivor 计算 ┌──────────────────────────────────────────────────────────────────┐ │ SurvivorRatio4 的效果 │ │ │ │ 年轻代 2.7GB Eden(2.16GB) Survivor0(0.27GB) Survivor1(0.27GB) │ │ │ │ 容量扩大150MB → 270MB增加 80% │ │ 晋升阈值MaxTenuringThreshold15原来动态约 6-8 │ │ │ │ 效果预估 │ │ - Survivor 能吸收峰值对象量翻倍 │ │ - 对象有更多机会在 Survivor 中被回收 │ │ - Full GC 频率预期3分钟 → 6小时提升 120 倍 │ │ │ └──────────────────────────────────────────────────────────────────┘四、效果验证4.1 调优后 GC 日志# 调优后监控数据24 小时后$ jstat-gcutil12345100010# 输出# S0 S1 E O M YGC YGCT FGC FGCT GCT# 5.30 0.00 45.00 68.50 82.10 512 78.90 12 15.60 94.50# 关键改善# - O老年代: 95.5% → 68.5% ↓空间充足# - FGCFull GC: 189 → 12 ↓减少 94%# - FGCTFull GC 耗时: 234s → 15.6s ↓4.2 长期稳定性调优后 30 天监控数据 ┌──────────────────────────────────────────────────────────────────┐ │ 指标 │ 调优前 │ 调优后 │ 改善 │ ├─────────────────────────┼─────────────┼─────────────┼─────────┤ │ Full GC 频率 │ 20次/小时 │ 0.03次/小时 │ 99.8%↓ │ │ Full GC 总耗时 │ 5.2小时/天 │ 0.3小时/天 │ 94%↓ │ │ Old Gen 平均使用率 │ 92% │ 65% │ 27%↓ │ │ 服务可用性 │ 98.5% │ 99.9% │ 1.4%↑ │ │ 接口 TP99 │ 5s │ 200ms │ 96%↓ │ └─────────────────────────┴─────────────┴─────────────┴─────────┘五、经验总结5.1 问题排查流程┌──────────────────────────────────────────────────────────────────┐ │ Full GC 排查流程 │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ Step 1: 确认 Full GC 类型 │ │ └→ Allocation Failure / Ergonomics / System.gc() / Metaspace │ │ │ │ Step 2: 分析 GC 日志 │ │ └→ Minor GC 频率 / 晋升量 / 老年代增长曲线 │ │ │ │ Step 3: jstat 实时监控 │ │ └→ Survivor 使用率 / 老年代使用率趋势 │ │ │ │ Step 4: jmap 堆分析 │ │ └→ 大对象类型 / 对象数量异常 │ │ │ │ Step 5: 代码审查 │ │ └→ 对象创建热点 / 缓存泄漏 / 静态集合 │ │ │ └──────────────────────────────────────────────────────────────────┘5.2 预防措施# 生产环境 JVM 配置检查清单# 1. SurvivorRatio 建议 4不要用默认的 8# 2. MaxTenuringThreshold 建议显式设置 10# 3. TargetSurvivorRatio 建议设置 90让 Survivor 充分利用# 4. GC 日志必开记录晋升年龄分布# 5. 配置告警Old Gen 80% 持续 5 分钟触发告警系列导航上一篇【JVM深度解析】第13篇生产环境JVM配置最佳实践下一篇【JVM深度解析】第15篇JVM配置优化案例二内存泄漏定位与修复MAT分析全流程系列目录JVM深度解析系列全集参考资料G1 GC调优指南Eclipse MAT使用指南JVM内存分配与回收