JVM实战（26）——SystemGC

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

一、案例背景

本章将介绍一个因为程序员同学不懂JVM的GC机制而导致的系统卡死的案例。

首先，这个系统上线之后，平时都还算正常，结果有一次大促活动的时候，系统直接卡死不动了。这个时候，我们首先想到的是可不可能是因为频繁Full GC导致Stop the World，正常工作线程无法执行。

1.1 存在问题

我们通过jstat进行分析，发现JVM中各个区域的内存使用都正常，新生代对象增长也不快，老年代也才使用了10%左右的空间，永久代也就使用了20%。

但是，jstat日志显示，JVM竟然每秒执行一次Full GC，每次都耗时几百毫秒。

既然Java堆内存都正常，为啥会频繁Full GC？这是我们立马想到，是不是有开发人员在代码中写了System.gc()这种代码，结果通过代码走查，发现确实如此。

二、System.gc方法

2.1 优化前

开发同学写System.gc()这行代码的思路是这样的：某段代码会一下子加载了好多数据，处理完成后这批数据就不用了，占用太多内存，所以就干脆显示调用GC方法把它们回收掉吧。

结果在平时没什么问题，因为流量很低。但是大促期间，访问量很高，System.gc()方法被频繁调用，因此频繁触发Full GC，从而导致了上述问题。

2.2 优化后

针对这个问题，解决方案就是 禁止在代码中显式调用System.gc()方法 ，GC完全交由JVM自己去处理，可以通过配置JVM参数-XX:+DisableExplicitGC来强制屏蔽。

三、总结

针对本章案例中的问题，我们平时自己写代码时，不要自己去调用System.gc()方法随便触发GC，一方面可以通过在JVM参数中加入-XX:+DisableExplicitGC显示禁止代码中的GC操作，另一方面也要加强对开发人员的JVM相关知识的培训。