【JVM】线上一次fullGC排查思路

监控告警发现，今天开始我们线上应用频繁出现fullGC，并且每次出现后磁盘都会被占满

查看监控发现FULLGC的机器均为同一个机房的集器，并且该机房有线上error报错，数据库监控对应的时间点也有异常，从今天的时间点开始，线上就频繁出现fullgc，并且磁盘一直告警。告警出现得很有规律，大概隔五分钟出现一次，每次出现后都会导致应用出现fullgc，影响系统稳定性。

对象分配到JVM的内存空间，是有分配策略的，比如：

(1)、大对象优先分配老年代

(2)、对象优先分配到年轻代的 Eden区，然后是 servicer1区，然后是老年代

(3)、老对象也会放到老年代

(4)、分配担保：就是在年轻代的两个区都放不下的时候，就分配到老年代，如果老年代也放不下了，那么就会进行fullGC

我们进行dump日志查看，发现每次fullGC时都有一个大VO对象，占用很大的内存（线上数据不方便贴图，这里举个别的例子）

在这里插入图片描述
说明本次内存泄漏的根本原因是跟该对象有关

再仔细观察堆内内存使用情况发现发生fullgc后，老年代该对象就可以正常回收，说明该对象的因为过大而直接进入老年代的，本来如果是小对象就会直接被YGC回收的。

查看代码发现，我们dao层中存在一个sql直接返回了全量数据库对象，导致每次捞取后就直接进入了老年代，执行完后也没有被回收。fullgc每次隔一段时间就发生，是因为该调用链路是一个定时任务，把该条数据订正后，fullGC也恢复正常了

这是因为我们当时配置了自动dump的参数，每次fullgc后都会去dump日志，并且dump的日志太大，占用了很大的磁盘空间，导致线上一直在告警

原文地址：https://blog.csdn.net/xiazi0721/article/details/136287139