本文主要是介绍【JVM】线上一次fullGC排查思路，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
fullGC问题背景
监控告警发现，今天开始我们线上应用频繁出现fullGC，并且每次出现后磁盘都会被占满
查看监控
查看监控发现FULLGC的机器均为同一个机房的集器，并且该机房有线上error报错，数据库监控对应的时间点也有异常，从今天的时间点开始，线上就频繁出现fullgc，并且磁盘一直告警。告警出现得很有规律，大概隔五分钟出现一次，每次出现后都会导致应用出现fullgc，影响系统稳定性。
确认fullGC的原因
对象分配到JVM的内存空间，是有分配策略的，比如：
(1)、大对象优先分配老年代
(2)、对象优先分配到年轻代的 Eden区，然后是 servicer1区，然后是老年代
(3)、老对象也会放到老年代
(4)、分配担保： 就是在年轻代的两个区都放不下的时候，就分配到老年代，如果老年代也放不下了，那么就会进行fullGC
我们进行dump日志查看，发现每次fullGC时都有一个大VO对象，占用很大的内存（线上数据不方便贴图，这里举个别的例子）
说明本次内存泄漏的根本原因是跟该对象有关
再仔细观察堆内内存使用情况发现发生fullgc后，老年代该对象就可以正常回收，说明该对象的因为过大而直接进入老年代的，本来如果是小对象就会直接被YGC回收的。
查看代码确认该对象来源
查看代码发现，我们dao层中存在一个sql直接返回了全量数据库对象，导致每次捞取后就直接进入了老年代，执行完后也没有被回收。fullgc每次隔一段时间就发生，是因为该调用链路是一个定时任务，把该条数据订正后，fullGC也恢复正常了
查看为什么fullgc后磁盘会被占满
这是因为我们当时配置了自动dump的参数，每次fullgc后都会去dump日志，并且dump的日志太大，占用了很大的磁盘空间，导致线上一直在告警
这篇关于【JVM】线上一次fullGC排查思路的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
