FULLGC的发生在应用里经常会有，怎么才算的上是频繁？我个人理解如果每天发生2次以上应该就算的上是频繁，FULLGC发生也会为我们的应用带来一些问题，比如会发生gc stw(stop the world),会停止所有的工作线程，如果gc时间很长的话，有些带有心跳的应用软件，会认为应用不在存活，做出一些错误的处理等。
这里给大家分享一下，FULLGC的一个协查的思路，因为gc发生的原因会因为业务不同，会有很多不同步的优化和处理方法，这里不做讨论
通常的处理，我们还是要在FULLGC时取到当时的dump文件，来分析内存里都有哪些数据占居着内存。这里有两种办法来获取dump文件：
1.通过在jvm里添加参数配置：+HeapDumpBeforeFullGC，+HeapDumpAfterFullGC
这种方法需要在应用启动前要提前配置好，如果不需要的话，还还需要修改jvm参数重启应用
2.使用jinfo命令进行设置。（生产环境常用的方法）
无需重启vm，即时生效，dump文件生成后，清除VM参数，通常fullgc 会频繁发生，不需要一直导出dump，所以拿到一次的dump采样后， 即可清除，然后慢慢分析dump文件
第一步，通过jps获得java程序的pid（jps,ps等方法）
#jps
5940 Main
3012 Jps
第二步，调用jinfo命令设置VM参数
#jinfo -flag +HeapDumpBeforeFullGC 5940
#jinfo -flag +HeapDumpAfterFullGC 5940
使用 #jinfo -flags pid 检查有没有生效
如果看到红框里的参数，就说明已经生效了，这里要注意：有些同学，通过ps等命令来查看jvm参数里没有，以为没有生效，这里因为是临时设置的参数，ps里是看不到的，下次jvm启动这些设置也都会失效
下次发生fullgc时就会生成dump文件，如果找不到文件记得配置dump的文件存放路径可使用参数-XX:HeapDumpPath=/temp/
dump文件取到后我们就可以清除原来设置的参数：
#jinfo -flag -HeapDumpBeforeFullGC 5940
#jinfo -flag -HeapDumpAfterFullGC 5940
使用 #jinfo -flags pid 检查有没有生效
如果看到红框里的参数，就说明已经生效了，这里要注意：我们对比清楚后，参数并没有消失，只是最前方向的“+” 变成了“-” ，这里“-”代表参数已经失效啦！
我们可以参考一个jinfo的帮助说明：
dump文件的分析，我们就可以借助MAT等工具分析，这里大家可参考：通过mybatis源码，分析一次由mybatis使用不当导致的OutOfMemoryError的协查 这里不再赘余。