米哈游Java面试被问：线上Full GC频繁，如何定位？CMS并发失败怎么办？

线上 Full GC 频繁：定位与 CMS 并发失败解决指南

一、Full GC 频繁的完整排查流程

1. 核心排查工具链

bash

# 1. 监控与数据收集 jstat -gcutil <pid> 1000 10 # 实时GC统计，每秒1次，共10次 jmap -histo:live <pid> | head -20 # 查看存活对象分布（触发Full GC） jmap -dump:live,format=b,file=heap.hprof <pid> # 生产环境谨慎使用 # 2. 实时诊断 jstack <pid> > thread.txt # 线程栈分析 jcmd <pid> GC.heap_info # 堆信息（JDK 7u40+） jcmd <pid> VM.flags # 查看JVM参数 # 3. 新一代诊断工具（JDK 8+） jhsdb jmap --heap --pid <pid> # 替代jmap -heap jcmd <pid> GC.class_histogram # 替代jmap -histo

2. 四步快速定位法

java

public class FullGCTroubleshooting { // 步骤1：确认现象 - 通过监控告警 // GC日志关键指标： // - Full GC频率：> 1次/分钟就是异常 // - Full GC耗时：> 1秒就是严重 // - Full GC前后堆变化：回收效果差 // 步骤2：分析GC日志（必须开启） // JVM参数：-Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps // -XX:+PrintTenuringDistribution -XX:+PrintPromotionFailure } // 示例GC日志分析 /* 2024-01-01T12:00:00.123+0800: [Full GC (Allocation Failure) [PSYoungGen: 2048K->0K(2560K)] [ParOldGen: 40960K->40959K(40960K)] 43008K->40959K(43520K), [Metaspace: 8192K->8192K(8192K)], 1.234567 secs] 关键信息： 1. 触发原因：Allocation Failure（分配失败） 2. 各区域回收效果：Old区几乎没回收（40960K->40959K） 3. 耗时：1.23秒（太长了！） */

3. 常见原因与症状对应表

二、CMS 并发失败详解与解决方案

1. CMS GC 流程回顾

text

CMS 六个阶段： 1. Initial Mark（初始标记） STW - 标记GC Roots直接引用 2. Concurrent Mark（并发标记） 并发 - 标记存活对象 3. Concurrent Preclean（并发预清理） 并发 - 处理并发期间的引用变化 4. Remark（重新标记） STW - 修正并发标记期间的变化 5. Concurrent Sweep（并发清除） 并发 - 清理垃圾 6. Concurrent Reset（并发重置） 并发 - 重置状态

2. 并发失败（Concurrent Mode Failure）原理

java

// 并发失败的发生场景 public class ConcurrentModeFailure { /* 根本原因：并发标记清理期间，新对象分配过快， Old区空间被快速填充，导致新对象没有足够空间。 触发条件： 1. 程序在并发标记期间分配了大量新对象 2. 这些对象晋升到Old区（或者大对象直接分配） 3. Old区剩余空间不足，无法完成并发清理 JVM的应对：退化到Serial Old GC（单线程Full GC） 这是STW时间长的罪魁祸首！ */ } // GC日志中的并发失败 /* [Full GC (CMS Initial Mark) [1 CMS-initial-mark: 349568K(349568K)] 362074K(506816K), 0.0030328 secs] [GC (CMS Concurrent Mode Failure) // ⚠️ 并发失败！ [1 CMS-initial-mark: 349568K(349568K)] 362074K(506816K), 0.0030328 secs] */

3. CMS 并发失败的四种场景

场景1：内存碎片导致晋升失败

bash

# 现象：虽然有足够总空间，但找不到连续空间存放大对象 # 诊断：查看GC日志中的Promotion Failed [ParNew (promotion failed): 2097152K->2097152K(2097152K), 0.0000123 secs] # 解决方案： # 1. 减小对象大小或拆分大对象 # 2. 调整 -XX:CMSFullGCsBeforeCompaction=N（N次Full GC后整理碎片） # 3. 考虑使用G1（自动整理碎片）

场景2：Old区预留空间不足

bash

# 现象：-XX:CMSInitiatingOccupancyFraction 设置过高 # 默认68%，如果程序分配很快，可能来不及完成并发清理 # 优化方案： # 1. 降低触发阈值 -XX:CMSInitiatingOccupancyFraction=60 # 从68%降到60% # 2. 开启浮动垃圾预测（JDK 7u4+） -XX:+UseCMSInitiatingOccupancyOnly # 禁用自动调整 -XX:+CMSScavengeBeforeRemark # Remark前强制YGC -XX:+CMSConcurrentMTEnabled # 启用并发线程

场景3：Young区过小导致频繁晋升

篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafc

需要全套面试笔记及答案
【点击此处即可/免费获取】​​​

java

// 如果Young区太小，对象很快晋升到Old区 // 验证：查看晋升年龄分布 // -XX:+PrintTenuringDistribution 输出 // 优化示例： public class YoungGenOptimize { /* 原始配置（问题）： -Xms4g -Xmx4g -Xmn1g // Young区只有1G 优化配置： -Xms4g -Xmx4g -Xmn2g // Young区扩大到2G -XX:SurvivorRatio=8 // Eden:Survivor=8:1:1 -XX:MaxTenuringThreshold=5 // 适当降低晋升年龄 */ }

场景4：大对象直接分配

java

// 大对象直接进入Old区（超过 -XX:PretenureSizeThreshold） public class BigObjectProblem { private static final int MB = 1024 * 1024; public void createBigObjects() { // 超过3MB的对象直接进入Old区（如果 -XX:PretenureSizeThreshold=3M） byte[] bigArray = new byte[4 * MB]; // 直接进Old区！ // 解决方案： // 1. 调整阈值（不推荐，治标不治本） // -XX:PretenureSizeThreshold=5242880 // 5MB // 2. 优化代码：使用对象池、拆分大对象 ByteBuffer buffer = ByteBuffer.allocateDirect(4 * MB); // 堆外内存 } }

4. CMS 参数调优矩阵

bash

# 基础参数 -XX:+UseConcMarkSweepGC # 启用CMS -XX:+UseParNewGC # Young区使用ParNew # 触发时机控制 -XX:CMSInitiatingOccupancyFraction=68 # Old区占用率触发百分比 -XX:+UseCMSInitiatingOccupancyOnly # 只按占用率触发 # 减少STW时间 -XX:+CMSParallelRemarkEnabled # 并行重新标记 -XX:+CMSScavengeBeforeRemark # Remark前强制YGC（减少重新标记时间） -XX:+CMSConcurrentMTEnabled # 并发阶段启用多线程（JDK 7u4+） # 解决碎片问题 -XX:+UseCMSCompactAtFullCollection # Full GC时整理碎片 -XX:CMSFullGCsBeforeCompaction=0 # 每次Full GC都整理（影响性能） -XX:CMSFullGCsBeforeCompaction=5 # 每5次Full GC整理一次（平衡） # 针对大对象优化 -XX:PretenureSizeThreshold=1048576 # 1MB以上直接进Old区 -XX:+CMSParallelInitialMarkEnabled # 并行初始标记

三、CMS 调优实战案例

案例1：电商大促期间的 CMS 调优

bash

# 初始配置（问题：频繁并发失败） -Xms8g -Xmx8g -Xmn2g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 # 问题分析： # 1. Young区太小（2G/8G=25%），对象快速晋升 # 2. 触发阈值75%太高，预留空间不足 # 优化后配置： -Xms8g -Xmx8g -Xmn3g # Young区扩大到3G -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60 # 降低触发阈值 -XX:+CMSScavengeBeforeRemark # Remark前强制YGC -XX:+CMSParallelRemarkEnabled # 并行Remark -XX:+UseCMSInitiatingOccupancyOnly # 固定阈值 -XX:SurvivorRatio=8 # Eden:S0:S1=8:1:1

案例2：内存泄漏导致的 CMS 失败

java

// 现象：Old区使用率持续上升，Full GC后回收很少 // 诊断步骤： // 1. 连续dump两次heap，对比分析 jmap -dump:live,format=b,file=heap1.hprof <pid> # 等待10分钟 jmap -dump:live,format=b,file=heap2.hprof <pid> // 2. 使用MAT分析 // 打开两个dump文件 → Histogram → Compare Tables // 查看增长最快的对象 // 3. 常见泄漏模式 public class MemoryLeakPatterns { // 模式1：静态集合累积 private static final Map<String, Object> CACHE = new HashMap<>(); // 模式2：ThreadLocal未清理 private static final ThreadLocal<byte[]> threadLocal = new ThreadLocal<>(); // 模式3：连接未关闭 public void leakConnection() { Connection conn = getConnection(); // 忘记conn.close() } // 模式4：监听器未移除 eventBus.register(this); // 忘记unregister }

案例3：Metaspace 泄漏

bash

# 现象：Metaspace持续增长，触发Full GC # 诊断：查看类加载器 jcmd <pid> GC.class_stats # JDK 8u40+ jcmd <pid> VM.class_hierarchy # 查看类层次 # 常见原因： # 1. 动态生成类（反射、动态代理） # 2. 热部署框架（Spring Boot DevTools） # 3. 类加载器泄漏 # 解决方案： # 1. 限制Metaspace大小 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m # 2. 监控类加载数量 jstat -gc <pid> 1000 | awk '{print $13, $14}' # MC/MU列 # 3. 修复代码：避免重复创建类 if (enhancerClass == null) { enhancerClass = enhancer.createClass(); // 缓存生成的类 }

四、CMS 到 G1 的迁移指南

何时应该从 CMS 切换到 G1？

bash

# 评估标准： # ✅ 堆内存 ≥ 4GB # ✅ 停顿时间要求高（< 200ms） # ✅ 应用有周期性Full GC # ✅ CPU资源充足（G1需要更多CPU） # 不建议切G1的场景： # ❌ 堆内存 < 4GB（CMS更高效） # ❌ CPU资源紧张（G1并发阶段耗CPU） # ❌ 吞吐量优先的应用

CMS → G1 配置迁移示例

bash

# CMS 配置 -Xms8g -Xmx8g -Xmn2g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=68 # 等效的 G1 配置 -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 # 目标停顿时间 -XX:G1HeapRegionSize=4m # Region大小（建议4-32M） -XX:InitiatingHeapOccupancyPercent=45 # 触发混合GC的堆占用率 -XX:ConcGCThreads=4 # 并发GC线程数 -XX:ParallelGCThreads=8 # 并行GC线程数

G1 解决 CMS 问题的优势

java

public class G1Advantages { /* 1. 预测性停顿：-XX:MaxGCPauseMillis 控制目标停顿时间 2. 分区管理：避免全局Full GC（只在极端情况发生） 3. 智能回收：优先回收垃圾最多Region 4. 内存整理：并发整理，避免碎片 5. 大对象处理：Humongous Region专门处理大对象 */ }

五、线上应急处理流程

1. 四步应急处理法

bash

# 第一步：快速止血（临时方案） # 1. 立即扩容：增加堆内存（如果有资源） # 2. 重启服务：临时解决内存泄漏问题 # 3. 流量降级：减少进入系统的请求 # 第二步：紧急参数调整（无需重启） # 添加以下参数，通过jinfo动态生效（JDK 8+） jinfo -flag +PrintGCDetails <pid> # 开启详细日志 jinfo -flag CMSInitiatingOccupancyFraction=55 <pid> # 降低触发阈值 jinfo -flag +DisableExplicitGC <pid> # 禁止System.gc() # 第三步：数据收集（为后续分析准备） # 1. 保存当前GC日志 # 2. 保存jstack输出 # 3. 保存jmap -histo输出 # 4. 如果条件允许，dump heap（注意服务影响） # 第四步：根因分析与修复

2. 关键监控指标与阈值

yaml

# GC健康度监控指标（建议告警阈值） gc_metrics: full_gc_frequency: # Full GC频率 warning: > 1次/分钟 critical: > 5次/分钟 full_gc_duration: # Full GC耗时 warning: > 1秒 critical: > 5秒 old_gen_usage: # Old区使用率 warning: > 80% critical: > 90% gc_overhead: # GC时间占比 warning: > 10% # 超过10%的CPU时间在GC critical: > 30%

3. 自动化诊断脚本示例

bash

#!/bin/bash # auto_gc_diagnosis.sh PID=$1 LOG_DIR="/tmp/gc_diagnosis_$(date +%Y%m%d_%H%M%S)" mkdir -p $LOG_DIR echo "开始GC问题诊断，PID: $PID" # 1. 收集基础信息 jcmd $PID VM.flags > $LOG_DIR/jvm_flags.txt jcmd $PID VM.version > $LOG_DIR/jvm_version.txt # 2. 实时采样（持续10秒） echo "采样GC状态..." for i in {1..10}; do jstat -gcutil $PID >> $LOG_DIR/gc_stats.log sleep 1 done # 3. 线程分析 jstack $PID > $LOG_DIR/thread_dump.txt # 4. 对象分布（触发Full GC，谨慎使用） # jmap -histo:live $PID | head -50 > $LOG_DIR/live_objects.txt # 5. 分析GC日志（如果有） if [ -f gc.log ]; then tail -1000 gc.log > $LOG_DIR/gc_tail.log # 分析Full GC频率 grep "Full GC" gc.log | wc -l > $LOG_DIR/full_gc_count.txt fi echo "诊断完成，结果保存在: $LOG_DIR" echo "主要检查：" echo "1. GC频率: cat $LOG_DIR/gc_stats.log" echo "2. 线程状态: cat $LOG_DIR/thread_dump.txt | grep -A5 -B5 'BLOCKED'" echo "3. JVM参数: cat $LOG_DIR/jvm_flags.txt | grep -E '(UseConcMarkSweep|HeapSize|SurvivorRatio)'"

六、长期预防与最佳实践

篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafc

需要全套面试笔记及答案
【点击此处即可/免费获取】​​​

1. 开发规范

java

public class GCBestPractices { // 1. 避免大对象 // ❌ 错误 byte[] hugeArray = new byte[10 * 1024 * 1024]; // 10MB // ✅ 正确 List<byte[]> chunks = new ArrayList<>(); for (int i = 0; i < 10; i++) { chunks.add(new byte[1 * 1024 * 1024]); // 1MB分块 } // 2. 及时释放引用 public void process() { List<Data> dataList = loadHugeData(); try { // 处理数据... } finally { dataList.clear(); // 帮助GC dataList = null; // 消除引用 } } // 3. 谨慎使用System.gc() // 使用JVM参数禁用：-XX:+DisableExplicitGC // 4. 合理使用缓存 // 使用软引用/弱引用缓存 Map<String, SoftReference<BigObject>> cache = new HashMap<>(); }

2. 压测与容量规划

bash

# 压测期间必须监控GC # 使用GCEasy等工具分析GC日志 # 容量规划公式： # 需要的堆内存 = 常驻内存 × 安全系数(1.5) + 峰值内存 # 示例： # 常驻内存：2GB（通过监控获得） # 峰值内存：1GB（大促期间） # 推荐配置： (2GB × 1.5) + 1GB = 4GB # JVM参数： -Xms4g -Xmx4g

3. 新一代GC选择建议

yaml

# 2024年GC选择指南（JDK 17+）： 场景推荐: 低延迟微服务: - JDK版本: 11+ - GC选择: G1或ZGC - 关键参数: - -XX:+UseZGC (JDK 15+生产可用) - -XX:MaxGCPauseMillis=100 大数据/计算密集型: - JDK版本: 8/11 - GC选择: Parallel (吞吐量优先) - 关键参数: - -XX:+UseParallelGC - -XX:ParallelGCThreads=CPU核心数 超大堆内存(>32GB): - JDK版本: 17+ - GC选择: ZGC或Shenandoah - 关键参数: - -XX:+UseZGC -Xmx64g - -XX:+UseShenandoahGC (RedHat JDK) CMS遗留系统: - 建议: 迁移到G1或升级JDK - 注意: JDK 14已移除CMS

总结：Full GC频繁的核心是及早发现、准确定位、快速解决。CMS并发失败的关键在于预留足够空间、减少碎片、控制晋升速度。对于新系统，建议直接使用G1或ZGC；对于CMS老系统，可根据实际情况优化或迁移。