GC日志分析实战用GCEasy快速定位JVM内存泄漏最近在排查一个线上服务性能问题时发现FullGC频率异常升高虽然暂时没有直接影响业务但作为技术负责人我知道这就像定时炸弹一样随时可能引爆。经过一番折腾最终通过GCEasy这个神器快速定位到了问题根源。今天就来分享下这次实战经验希望能帮到遇到类似问题的朋友。1. 问题初现与基础排查那天早上监控系统突然报警显示某核心服务的FullGC次数从平时的每天几次飙升到每小时几十次。第一反应是登录服务器用jstat看看实时情况jstat -gcutil pid 1000输出结果中几个关键指标引起了我的注意Old区使用率O%始终在75%-85%之间波动FullGC次数FGC以每分钟1-2次的频率稳定增长FullGC耗时FGCT单次耗时在800ms-1.2s之间更奇怪的是每次FullGC后老年代内存释放非常有限这排除了老年代空间不足的常见原因。此时我意识到需要更详细的GC日志来分析。2. 获取并分析GC日志要获取有价值的GC日志需要在JVM启动参数中加入以下配置-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/path/to/gc.log等待日志积累一段时间后我下载了大约4小时的gc.log文件。面对数万行的日志文本直接阅读显然不现实。这时GCEasy就派上了用场。将日志文件上传到GCEasy后几分钟内就生成了十几张可视化图表。其中几张关键图表揭示了问题堆内存变化趋势图显示老年代内存在FullGC前后变化不大仅2-3%的波动新生代回收效果正常GC原因统计图更让人震惊78%的FullGC由System.gc()调用触发只有22%是因为空间不足3. 追踪System.gc()调用源既然大部分FullGC是人为调用System.gc()导致的接下来就需要找出是谁在调用。传统方法需要加JVM参数-XX:DisableExplicitGC然后观察FullGC频率变化但这只能验证猜测不能定位具体代码位置。更高效的做法是使用Arthas进行动态追踪# 启动Arthas java -jar arthas-boot.jar # 开启不安全操作允许监控JDK方法 options unsafe true # 监控System.gc()调用栈 stack java.lang.System gc等待几分钟后Arthas捕获到了完整的调用链最终定位到一个日期工具类中的异常处理块public static Date stringToDate(String str, String format) { try { return new SimpleDateFormat(format).parse(str); } catch (Exception e) { e.printStackTrace(); System.gc(); // 问题根源 return null; } }更糟的是这个工具方法被用在了一个批量处理的循环中导致System.gc()被频繁调用。4. 问题修复与优化建议定位到问题后解决方案很简单 - 删除无意义的System.gc()调用。但这次经历让我总结出几个重要经验GC日志收集应该成为线上服务的标配推荐配置-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:HeapDumpOnOutOfMemoryError -Xloggc:/path/to/gc_%p_%t.log谨慎使用System.gc()除非有非常特殊的场景否则应该用-XX:DisableExplicitGC禁用显式GC或者用-XX:ExplicitGCInvokesConcurrent让System.gc()触发并发GC建立GC监控体系建议监控以下指标指标名称报警阈值监控频率FullGC次数5次/小时每分钟YoungGC耗时200ms每分钟Old区使用率80%持续10分钟每分钟5. 高级分析技巧对于更复杂的内存问题可以结合多种工具内存快照分析jmap -dump:live,formatb,fileheap.hprof pid实时监控# 监控对象创建 arthas monitor -c 5 com.example.ClassA * # 追踪方法调用 arthas trace com.example.ServiceA methodAJVM调优检查表[ ] 新生代大小是否合理-Xmn[ ] 是否启用CMS或G1垃圾回收器[ ] 元空间大小是否足够-XX:MetaspaceSize[ ] 是否设置了合理的GC目标-XX:MaxGCPauseMillis
GC日志分析实战：用GCEasy快速定位JVM内存泄漏（附FullGC排查案例）
GC日志分析实战用GCEasy快速定位JVM内存泄漏最近在排查一个线上服务性能问题时发现FullGC频率异常升高虽然暂时没有直接影响业务但作为技术负责人我知道这就像定时炸弹一样随时可能引爆。经过一番折腾最终通过GCEasy这个神器快速定位到了问题根源。今天就来分享下这次实战经验希望能帮到遇到类似问题的朋友。1. 问题初现与基础排查那天早上监控系统突然报警显示某核心服务的FullGC次数从平时的每天几次飙升到每小时几十次。第一反应是登录服务器用jstat看看实时情况jstat -gcutil pid 1000输出结果中几个关键指标引起了我的注意Old区使用率O%始终在75%-85%之间波动FullGC次数FGC以每分钟1-2次的频率稳定增长FullGC耗时FGCT单次耗时在800ms-1.2s之间更奇怪的是每次FullGC后老年代内存释放非常有限这排除了老年代空间不足的常见原因。此时我意识到需要更详细的GC日志来分析。2. 获取并分析GC日志要获取有价值的GC日志需要在JVM启动参数中加入以下配置-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/path/to/gc.log等待日志积累一段时间后我下载了大约4小时的gc.log文件。面对数万行的日志文本直接阅读显然不现实。这时GCEasy就派上了用场。将日志文件上传到GCEasy后几分钟内就生成了十几张可视化图表。其中几张关键图表揭示了问题堆内存变化趋势图显示老年代内存在FullGC前后变化不大仅2-3%的波动新生代回收效果正常GC原因统计图更让人震惊78%的FullGC由System.gc()调用触发只有22%是因为空间不足3. 追踪System.gc()调用源既然大部分FullGC是人为调用System.gc()导致的接下来就需要找出是谁在调用。传统方法需要加JVM参数-XX:DisableExplicitGC然后观察FullGC频率变化但这只能验证猜测不能定位具体代码位置。更高效的做法是使用Arthas进行动态追踪# 启动Arthas java -jar arthas-boot.jar # 开启不安全操作允许监控JDK方法 options unsafe true # 监控System.gc()调用栈 stack java.lang.System gc等待几分钟后Arthas捕获到了完整的调用链最终定位到一个日期工具类中的异常处理块public static Date stringToDate(String str, String format) { try { return new SimpleDateFormat(format).parse(str); } catch (Exception e) { e.printStackTrace(); System.gc(); // 问题根源 return null; } }更糟的是这个工具方法被用在了一个批量处理的循环中导致System.gc()被频繁调用。4. 问题修复与优化建议定位到问题后解决方案很简单 - 删除无意义的System.gc()调用。但这次经历让我总结出几个重要经验GC日志收集应该成为线上服务的标配推荐配置-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:HeapDumpOnOutOfMemoryError -Xloggc:/path/to/gc_%p_%t.log谨慎使用System.gc()除非有非常特殊的场景否则应该用-XX:DisableExplicitGC禁用显式GC或者用-XX:ExplicitGCInvokesConcurrent让System.gc()触发并发GC建立GC监控体系建议监控以下指标指标名称报警阈值监控频率FullGC次数5次/小时每分钟YoungGC耗时200ms每分钟Old区使用率80%持续10分钟每分钟5. 高级分析技巧对于更复杂的内存问题可以结合多种工具内存快照分析jmap -dump:live,formatb,fileheap.hprof pid实时监控# 监控对象创建 arthas monitor -c 5 com.example.ClassA * # 追踪方法调用 arthas trace com.example.ServiceA methodAJVM调优检查表[ ] 新生代大小是否合理-Xmn[ ] 是否启用CMS或G1垃圾回收器[ ] 元空间大小是否足够-XX:MetaspaceSize[ ] 是否设置了合理的GC目标-XX:MaxGCPauseMillis
